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>
