- 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