W3C home > Mailing lists > Public > whatwg@whatwg.org > November 2009

[whatwg] localStorage mutex - a solution?

From: Maciej Stachowiak <mjs@apple.com>
Date: Wed, 25 Nov 2009 16:35:38 -0800
Message-ID: <6110B47C-036E-45F0-A1B4-6327A3632321@apple.com>

On Nov 25, 2009, at 7:46 AM, Jeremy Orlow wrote:

> On Wed, Nov 25, 2009 at 6:20 AM, Ian Hickson <ian at hixie.ch> wrote:
> On Wed, 4 Nov 2009, Rob Ennals wrote:
> >
> > How about this for a solution for the localStorage mutex problem:  
> [...]
> Here's a proposal based on the recent feedback:
> * There is a per-origin mutex. It can be owned by either an event loop
>  task or a network layer task.
> * Things that wait until their task owns the storage mutex:
>   - script fetching document.cookie
>   - script setting document.cookie
>   - script reading or writing a property of, or calling a method on,  
> or
>     enumerating the properties of, the localStorage object
>   - the network layer setting cookies
> * Things that release the storage mutex if their task owns it:
>   - the network layer after it has set cookies
>   - script calling a method implemented in native code on a host  
> object
> Is this a may or a must?  As discussed, a may will result in  
> different behaviors and strange bugs when someone develops on one  
> browser and then tries to run their script on a different version of  
> that browser or different browsers since they will probably have  
> subtly different cases when they'll need to release the lock.  If  
> it's a must, then we'll take a small hit in all of our script  
> binding code, but things will be more interoperable.

Is there any observable difference between a "may" and a  
"must" (assuming the implementation has avoided deadlocks)? Dropping  
the mutex will just remove a guarantee, it won't force different  
behavior. You can still get lucky. Indeed, in a browser that only uses  
a single thread/process to render Web content, if you're not using  
workers you will always get lucky.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20091125/184e7a8e/attachment.htm>
Received on Wednesday, 25 November 2009 16:35:38 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:19 UTC