[whatwg] localStorage mutex - a solution?

[Maciej Stachowiak]

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.

Regards,
Maciej

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20091125/184e7a8e/attachment-0002.htm>