On 08/19/2011 08:14 PM, Thomas Bushnell, BSG wrote: > Sorry for breaking the threading, but I only just subscribed to the list > so I can't reply properly. > > I'm the origin of the patch recently posted by David Henningsson which > alters the way locking works. Maarten Bosmans had some questions I'd > like to address. > > 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. > > 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't know that Windows has read locks. > > 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. > > I am not wedded at all to the specific details of what the generic > functions in core-util.c do. > > 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. Hi Thomas and thanks for coming here! I have a question about the proposed handling. Assume that the cookie is wrong, and that two clients both find that out in parallel. Then they both want to promote their read lock to a write lock. What will happen in that case? -- David Henningsson, Canonical Ltd. http://launchpad.net/~diwic
