[pulseaudio-discuss] Making locking nicer for NFS
gmane at colin.guthr.ie
Sat Aug 20 06:30:48 PDT 2011
'Twas brillig, and Thomas Bushnell, BSG at 19/08/11 19:14 did gyre and
> 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 :)
Tribalogic Limited [http://www.tribalogic.net/]
Mageia Contributor [http://www.mageia.org/]
PulseAudio Hacker [http://www.pulseaudio.org/]
Trac Hacker [http://trac.edgewall.org/]
More information about the pulseaudio-discuss