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
_______________________________________________
pulseaudio-discuss mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
