Re: [dev] Re: [surf] cookie race condition for multiple instances?

On Thu, 3 Sep 2009 21:52:02 -0400
Ray Kohler <ataraxia937_AT_gmail.com> wrote:

> On Sun, Aug 30, 2009 at 9:53 PM, Ray Kohler<ataraxia937_AT_gmail.com> wrote:
> > I'm curious as to whether a race condition is created for access to
> > the soup cookie jar file when multiple instances of surf are running.
> > libsoup's docs don't mention any safety mechanisms for this object, so
> > I'm expecting trouble is possible. Does anyone actually know for sure?
>
> To answer my own question, after reading libsoup's source, I can say
> that this race does exist. Adding a cookie opens the file for append
> and writes it. Deleting one rewrites the file and filters the target
> cookie while doing so. Updating a cookie is just a delete and an add.
> Both kinds of writes open the file immediately before writing and
> close it immediately afterward, so at least it's not as big a problem
> as if it kept it open for the lifetime of the session.
>
> The easiest way to workaround this (suckless or not) is to use
> libsoup's sqlite cookie jar instead, so that's what I'm going to do.
> There is still another problem not solved by this - running sessions
> sharing a cookie jar trust their own memory cache of the file's
> contents never to get stale. Using sqlite will make sure the cookie
> jar ends up as the union of the outputs of all sessions, but it won't
> allow all these sessions to take advantage of each other's changes in
> real time. I don't consider this to be anywhere near as much of a
> problem as corruption or loss of data from the on-disk jar, though.
>

FWIW, in uzbl we use an external script to take care of cookie storage and retrieval.
wmich makes it easy to support concurrency and multiple instances can easily share the same script (storage).

Dieter
Received on Fri Sep 04 2009 - 07:13:55 UTC