[pulseaudio-discuss] Making locking nicer for NFS

[Maarten Bosmans]

I didn't get Thomas's original mail to the list, just Colin's reply,
something wrong there?

2011/8/20 Colin Guthrie <gmane at colin.guthr.ie>:
> 'Twas brillig, and Thomas Bushnell, BSG at 19/08/11 19:14 did gyre and
> gimble:
>> 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.

So scrap my earlier suggestion to fall back to pa_lock_fd in
pa_read_lock_fd, just put an pa_assert_not_reached at the end of
pa_read_lock_fd and I'll fix it for Windows later.

>> 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.

Fine, we'll use those semantics and I just have to find a way to
implement them on Windows. Could you add a comment to pa_read_lock_fd
on how it is supposed to be used?

>> 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.

Just a random suggestion: these locks look like they are blocking if
the file is already locked. Would returning immediately with an error
instead be another solution to the NFS problem?

> Thanks for the explanation.
>
> I'm sure the general principle is a good one and one that we'd like to
> adopt. Hopefully Maarten can help you come up with a solution that works
> for platform :)

Colin, were you thinking pre or post 1.0?

Maarten