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

When we had this discussion last, there was significant pushback on this -
the argument was basically "we have no evidence that cookie-based race
conditions *aren't* causing sporadic breakages", which is true. It's
inherently difficult to measure.
As an aside, I'll note that the majority of pushback came from developers of
platforms that were inherently single-threaded, and so enforcing
synchronicity had no impact on the performance of their platforms. It's easy
to be a purist when there's no cost.

Now that more browsers are moving to multi-process architectures and will
soon be faced with having to reduce the performance of their platforms to
enforce cookie coherence, I wonder if people's attitudes have changed. I,
too, would be interested in hearing if the folks working on multi-process
firefox are planning to implement this piece of the spec.

-atw

On Wed, Sep 2, 2009 at 9:55 AM, Darin Fisher <darin at chromium.org> wrote:

>
>
> 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/01d5289c/attachment.htm>

Received on Wednesday, 2 September 2009 10:17:26 UTC