[whatwg] localStorage mutex - a solution?

Ian Hickson ian at hixie.ch
Wed Nov 25 03:20:57 PST 2009


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
   - script setting document.domain
   - a task ending

Reading or writing a property on a native object doesn't do it, so 

   window['x'].document.forms['y'].value = 'foo';

...doesn't release the mutex, though this (identical code) would:

   window['x'].document.forms.namedItem('y').value = 'foo';

...because of namedItem() call.


Is this unacceptable to anyone?

Does anyone think that it would be better to enumerate a specific set of 
methods that reset the storage mutex instead? (i.e. the status quo)

I am especially interested in opinions from browser vendors, and amongst 
those primarily those browser vendors actually implementing this now.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'



More information about the whatwg mailing list