'Twas brillig, and Thomas Bushnell, BSG at 19/08/11 19:14 did gyre and gimble: > 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. Thanks for the explanation. I'm sure the general principle is a good one and one that we'd like to adopt. Hopefully Maarten can help you come up with a solution that works for platform :) Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited [http://www.tribalogic.net/] Open Source: Mageia Contributor [http://www.mageia.org/] PulseAudio Hacker [http://www.pulseaudio.org/] Trac Hacker [http://trac.edgewall.org/]
