- From: Darin Fisher <darin@chromium.org>
- Date: Wed, 2 Sep 2009 09:55:05 -0700
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.htm>
Received on Wednesday, 2 September 2009 09:55:05 UTC