Sorry for breaking the threading, but I only just subscribed to the list so I can&#39;t reply properly.<div><br></div><div>I&#39;m the origin of the patch recently posted by David Henningsson which alters the way locking works. Maarten Bosmans had some questions I&#39;d like to address.</div>
<div><br></div><div>The confusing formatting of the diff in core-util.c is just unidiff being clever. Basically I created a new function to wrap around fcntl to share the common code between pa_lock_fd and pa_read_lock_fd.</div>
<div><br></div><div>I have no objection of course to simply defining it unconditionally and using it always. I do not know Windows, so I was trying to make the minimally disruptive change. I didn&#39;t know that Windows has read locks.</div>
<div><br></div><div>In Unix, promoting a read lock to a write lock converts the lock--it does not add another lock--without releasing the readlock in the middle.</div><div><br></div><div>I am not wedded at all to the specific details of what the generic functions in core-util.c do.</div>
<div><br></div><div>The root issue is as David Henningsson explained. By using an exclusive lock, pulseaudio creates an unnecessary contention in reading the .pulse-cookie file, and because of the less-than-ideal (but quite unchangeable) behavior of NFSv3, this forces a thirty-second delay anytime two pulse clients try to read the cookie at the same time. Switching to a read lock for the read, and only using an exclusive lock when the cookie needs to be written (a much rarer operation), avoids this problem entirely.</div>
<div><br></div><div>Thomas</div>