[pulseaudio-discuss] Making locking nicer for NFS

Arun Raghavan arun.raghavan at collabora.co.uk
Mon Apr 2 23:20:52 PDT 2012


On Tue, 2012-04-03 at 07:54 +0200, David Henningsson wrote:
> 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.

D'oh! Makes sense. Filed a bug so we can get to it post 2.0:

https://bugs.freedesktop.org/show_bug.cgi?id=48226

-- Arun



More information about the pulseaudio-discuss mailing list