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
