This method also has the advantage of not relying on lock promotion semantics, which (apparently) will make the Windoze version easier. Thomas On Thu, Aug 25, 2011 at 10:30 AM, David Henningsson < david.henningsson at canonical.com> wrote: > 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 <david.henningsson at canonical.com> >> <mailto:david.henningsson@**canonical.com<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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/pulseaudio-discuss/attachments/20110825/1b066e55/attachment-0001.htm>
