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 > >> <[email protected]> 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 _______________________________________________ pulseaudio-discuss mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
