[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