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

[whatwg] localStorage mutex - a solution?

From: Ian Hickson <ian@hixie.ch>
Date: Wed, 25 Nov 2009 11:20:57 +0000 (UTC)
Message-ID: <Pine.LNX.4.62.0911251107210.10133@hixie.dreamhostps.com>
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.   `._.-(,_..'--(,_..'`-.;.'
Received on Wednesday, 25 November 2009 03:20:57 UTC

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