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

On Wed, Aug 26, 2009 at 3:24 PM, Jeremy Orlow <jorlow at chromium.org> wrote:

> On Wed, Aug 26, 2009 at 3:05 PM, Robert O'Callahan <robert at ocallahan.org>wrote:
>
>> On Wed, Aug 26, 2009 at 2:54 PM, Jeremy Orlow <jorlow at chromium.org>wrote:
>>
>>> Is there any data (or any way to collect the data) on how much of the web
>>> IE and Chrome's current behavior has broken?  Given that there hasn't been
>>> panic in the streets, I'm assuming approximately 0%?
>>>
>>
>> We previously had a lengthy discussion about this.
>>
>> If a site has a cookie race that causes a problem in IE/Chrome one in
>> every 10,000 page loads, are you comfortable with that?
>>
>
> I'm much more comfortable with that than the cost of a global mutex that
> all cookies and LocalStorage share.  There are other ways to come about this
> problem (like developer tools).
>
> I'm pretty sure Chromium has no intention of implementing a global storage
> mutex and putting all cookie access under it.  Has anyone heard anything
> (either way) from Microsoft?  Are there any browsers moving to a
> multi-event-loop (be it multi-threaded or multi-process) based model that
> intend to implement this?  If not, then it would seem like the spec is not
> grounded in reality.
>

Does the silence mean that no one has any intention of implementing this?
 If so, maybe we should resign ourselves to a break in the single threaded
illusion for cookies.  This doesn't seem too outlandish considering that web
servers working with cookies will never have such a guarantee and given that
we have no evidence of widespread breakage with IE 8 and Chrome.

If we were to get rid of the storage mutex for cookie manipulation (as I
believe we should) maybe we should re-examine it for local storage.  At a
minimum, it could be implemented as a per-origin mutex.  But I feel strongly
we should go further.  Why not have an asynchronous mechanism for atomic
updates?  For example, if I wanted to write an ATM application, I would have
to do the following:

var accountDelta = /* something */;
window.localStorage.executeAtomic(function() {
    localStorage.accountBalance = localStorage.accountBalance +
accountDelta;
}

Alternatively, we could make it so that each statement is atomic, but that
you have to use such a mechanism for anything more complicated. For example:

localStorage.accountBalance = localStorage.accountBalance + accountDelta;
 // It's atomic, so no worries!
var balance = localStorage.accountBalance;  /* Oh no!!!!  This isn't safe
since it's implemented via multiple statements... */
localStorage.accountBalance = balance + accountDelta;  /* ....we should have
used localStorage.executeAtomic! */

Such ideas would definitely lighten lock contention and possibly eliminate
the need for yieldForStorageUpdates (formerly getStorageUpdates).  Another
major bonus is that it'd allow us to expose localStorage to workers again,
which is one of the top complaints I've gotten when talking to web
developers about localStorage.

I know this is radical stuff, but the way things are speced currently just
are not practical.

J
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090902/cca07254/attachment.htm>

Received on Tuesday, 1 September 2009 16:31:22 UTC