On 08/21/2011 04:38 PM, Thomas Bushnell, BSG wrote: > Whoops. They need to repeat the read after obtaining the write lock and > only update the file if the contents are still bad in that case. Would a good handling of this be: 1) Open the cookie read-only 2) read the cookie 3) close file 4) if we have a correct cookie, do nothing more 5) if we have the wrong cookie, do the old handling unchanged: open with write lock, check the contents (again), and write if something is (still) wrong. > > On Aug 21, 2011 4:46 AM, "David Henningsson" > <david.henningsson at canonical.com > <mailto:david.henningsson at canonical.com>> wrote: > > 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 -- David Henningsson, Canonical Ltd. http://launchpad.net/~diwic
