[pulseaudio-discuss] Making locking nicer for NFS

[Thomas Bushnell, BSG]

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.

Thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/pulseaudio-discuss/attachments/20110819/63c62d87/attachment.html>