[whatwg] Storage mutex and cookies can lead to browser deadlock

[Drew Wilson]

On Thu, Sep 3, 2009 at 1:32 PM, Benjamin Smedberg <bsmedberg at mozilla.com>wrote:

> On 9/3/09 4:24 PM, Drew Wilson wrote:
> > I think the canonical racy case is "the page wants to keep a counter for
> > the number of times event X occurs" in a cookie or local storage.
> >
> > It doesn't seem to be possible to achieve this without the mutex - the
> > proposal below would break down if two pages tried to increment the
> > cookie value simultaneously (if both pages changed "cookieValue=3" to
> > "cookieValue=4" at the same time, the result of your merge step would
> > likely be "cookieValue=4", not "cookieValue=5" as one might intend).
>
> Is that case important? I think that it's more important to make sure that
> script doesn't inadvertently remove or modify cookies due to races in
> document.cookie, but that maintaining a single-threaded view of the cookie
> data is not desirable.
>

You're asking the wrong guy - I'm in the "don't bother trying to ensure
consistency" camp :) I'm just parroting the arguments that were offered
previously.

If I hadn't lost the arguments about providing workers access to cookies,
then I'd say that pages that care about cookie consistency should set
cookies via a SharedWorker. But failing that, it seems like the choices are
fairly stark: ensure consistency and take the performance hit in all
multi-threaded browsers, or explicitly disavow consistency, and console
ourselves by making our future APIs more multi-process friendly.

I do understand the point of view of the "correctness over performance" camp
- however, as Jeremy points out, it doesn't sound like those arguments have
gotten much traction with actual implementors yet.


>
> --BDS
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090903/09f087a2/attachment-0002.htm>