This method also has the advantage of not relying on lock promotion semantics, which (apparently) will make the Windoze version easier.<div><br></div><div>Thomas<br><br><div class="gmail_quote">On Thu, Aug 25, 2011 at 10:30 AM, David Henningsson <span dir="ltr"><<a href="mailto:david.henningsson@canonical.com">david.henningsson@canonical.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">On 08/21/2011 04:38 PM, Thomas Bushnell, BSG wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Whoops. They need to repeat the read after obtaining the write lock and<br>
only update the file if the contents are still bad in that case.<br>
</blockquote>
<br></div>
Would a good handling of this be:<br>
<br>
1) Open the cookie read-only<br>
2) read the cookie<br>
3) close file<br>
4) if we have a correct cookie, do nothing more<br>
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.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
<br>
On Aug 21, 2011 4:46 AM, "David Henningsson"<br>
<<a href="mailto:david.henningsson@canonical.com" target="_blank">david.henningsson@canonical.<u></u>com</a><br></div><div><div></div><div class="h5">
<mailto:<a href="mailto:david.henningsson@canonical.com" target="_blank">david.henningsson@<u></u>canonical.com</a>>> wrote:<br>
> On 08/19/2011 08:14 PM, Thomas Bushnell, BSG wrote:<br>
>> Sorry for breaking the threading, but I only just subscribed to the list<br>
>> so I can't reply properly.<br>
>><br>
>> I'm the origin of the patch recently posted by David Henningsson which<br>
>> alters the way locking works. Maarten Bosmans had some questions I'd<br>
>> like to address.<br>
>><br>
>> The confusing formatting of the diff in core-util.c is just unidiff<br>
>> being clever. Basically I created a new function to wrap around fcntl to<br>
>> share the common code between pa_lock_fd and pa_read_lock_fd.<br>
>><br>
>> I have no objection of course to simply defining it unconditionally and<br>
>> using it always. I do not know Windows, so I was trying to make the<br>
>> minimally disruptive change. I didn't know that Windows has read locks.<br>
>><br>
>> In Unix, promoting a read lock to a write lock converts the lock--it<br>
>> does not add another lock--without releasing the readlock in the middle.<br>
>><br>
>> I am not wedded at all to the specific details of what the generic<br>
>> functions in core-util.c do.<br>
>><br>
>> The root issue is as David Henningsson explained. By using an exclusive<br>
>> lock, pulseaudio creates an unnecessary contention in reading the<br>
>> .pulse-cookie file, and because of the less-than-ideal (but quite<br>
>> unchangeable) behavior of NFSv3, this forces a thirty-second delay<br>
>> anytime two pulse clients try to read the cookie at the same time.<br>
>> Switching to a read lock for the read, and only using an exclusive lock<br>
>> when the cookie needs to be written (a much rarer operation), avoids<br>
>> this problem entirely.<br>
><br>
> Hi Thomas and thanks for coming here!<br>
><br>
> I have a question about the proposed handling. Assume that the cookie is<br>
> wrong, and that two clients both find that out in parallel. Then they<br>
> both want to promote their read lock to a write lock. What will happen<br>
> in that case?<br>
><br>
> --<br>
> David Henningsson, Canonical Ltd.<br>
> <a href="http://launchpad.net/~diwic" target="_blank">http://launchpad.net/~diwic</a><br>
</div></div></blockquote><div class="HOEnZb"><div></div><div class="h5">
<br>
<br>
<br>
-- <br>
David Henningsson, Canonical Ltd.<br>
<a href="http://launchpad.net/~diwic" target="_blank">http://launchpad.net/~diwic</a><br>
</div></div></blockquote></div><br></div>