[pulseaudio-discuss] Pulse-cookie locking in NFS causes 30 second delays

[David Henningsson]

Hi,

I came across this bug:

https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/817269

Which claims the following (and also offers a patch [1] to fix it). I 
don't know much about file locking or NFS, but maybe someone here knows 
more than I here.

Quoting the bug:

Pulseaudio uses a cookie file (normally ~/.pulse-cookie). This file is 
manipulated by the code in src/pulsecore/authkey.c. Currently it does 
this to read the key:
1) Open the file
2) Acquire a write-lock for the file.
3) Read the file.
4) If the file is not a good cookie, generate a new cookie and write it 
to the file.
5) Close the file.

If more than one thread is opening the cookie at once, then there is 
contention at step (2) which is rarely necessary. Instead, step (2) 
should acquire only a read-lock, and then step (4) should promote that 
to a write-lock before writing the file.

This is particularly bad in the case where the .pulse-cookie file is on 
NFS. In that case, the lock contention forces a thirty-second backoff 
from whichever thread gets there second.

I am happy to work with y'all in engineering a patch for this. It 
requires obviously a change to src/pulsecore/authkey.c, and a 
corresponding one in src/pulsecore/core-util.c where the actual lock 
syscall occurs.

The following script (if ~ is in NFS) will demonstrate the problem. The 
two pactl processes both try to acquire the lock on the file 
simultaneously, and whichever one loses will take thirty seconds before 
it wins, because of the needless contention (and the unfortunate facts 
of how lockd in NFS works).

!/bin/bash

NUM_PROCS=2

procs=()
for i in $(seq 1 $NUM_PROCS); do
   pactl list > /dev/null &
   procs[$i]=$!
done
for i in $(seq 1 $NUM_PROCS); do
   wait ${procs[$i]}
done


-- 
David Henningsson, Canonical Ltd.
http://launchpad.net/~diwic

[1] https://launchpadlibrarian.net/77550336/use-read-locks