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

[Darin Fisher]

On Tue, Sep 1, 2009 at 4:31 PM, Jeremy Orlow <jorlow at chromium.org> wrote:

> 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.
>

IE 6 <-- it is also multi process.  you can poke at wininet from any
application and change the cookies for IE.

-darin



> 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/5bba334b/attachment-0002.htm>