[pulseaudio-discuss] Making locking nicer for NFS

[Arun Raghavan]

On Tue, 2012-04-03 at 15:08 +0530, Arun Raghavan wrote:
> On Tue, 2012-04-03 at 10:08 +0100, Colin Guthrie wrote:
> > 'Twas brillig, and David Henningsson at 03/04/12 06:54 did gyre and gimble:
> > > On 04/03/2012 06:27 AM, Arun Raghavan wrote:
> > >> On Thu, 2011-08-25 at 10:37 -0700, Thomas Bushnell, BSG wrote:
> > >>> 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.
> > >>
> > >> Thomas, David: Any news on this? Looks like we're agreed on an approach
> > >> and this "just" needs to be implemented now. :)
> > > 
> > > As I understand it, Thomas problem was solved somehow (see
> > > https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/817269/comments/8
> > > ), and thus nobody did anything.
> > > 
> > > In the long term, maybe the cookie should move to XDG_RUNTIME_DIR [1],
> > > which I understand would normally reside on a tmpfs, where this is not
> > > an issue in the first place.
> > 
> > The runtime dir will only affect the native protocol socket (and other
> > unix sockets we create I guess) a related NFS fix I pushed the other day
> > as you know: https://bugs.freedesktop.org/show_bug.cgi?id=44680
> > 
> > It would not actually help with the .pulse-cookie file which was what
> > this thread started as.
> > 
> > So I think the general principle probably still stands here.
> 
> The original problem appeared to be related locking on NFS. Moving
> transient data to local storage (which I presume the runtime directory
> would be) should also solve this problem, right?

Whoops, sent this before I saw your comments on the bug :/

-- Arun