[whatwg] localStorage mutex - a solution?

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.


>   - 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.
>

On the rest of the questions, I don't have a strong opinion.  Maybe Darin
(the other Chromium guy who's deep in the trenches with this stuff) will.


-----------------------------


I know that we've discussed approximations of run to completion before, but
maybe it's worth one more shot:  What if on the first use of document.cookie
or local storage we took a snapshot of both and used that during the task's
execution.  All writes would be queued up until the task finishes, at which
point they'd be written to the central version of the cookie and/or local
storage.  This would provide a consistent view of data for the duration of
the task and would solve almost all the atomicity problems except
|document.cookie = document.cookie + "foo";|.  For that, I'd suggest adding
a method that allows scripts to do atomic modifications to storage within a
callback.

I can understand everyone's desire to have completely serializable semantics
for local storage access and cookies (if you don't count the servers'
interaction with them), but maybe we need to go back to use cases.  In a
world with WebDatabase/WebSimpleDB, I really don't see anyone turning to
LocalStorage except for more basic uses.  Most of which I'm guessing
need consistent reads much more than serialization of everything.

And let's be realistic.  IE has had this problem with document.cookie for a
long time.  And IE8 now has this problem with localStorage.  Given that in
the best case (MS and all others implement the storage mutex) web developers
will not be able to assume localStorage and document.cookie access is atomic
for many years at a minimum, I think we're being pretty unrealistic about
how much the storage mutex is going to improve anyone's life.  Let's come up
with an approximation, give developers a callback for atomic access, and be
done with it.

J

P.S.  Chrome is going to ship without locking, but since we auto-update all
of our users, these problems won't necessarily persist for many years just
because we shipped it.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20091125/a276d9f3/attachment.htm>

Received on Wednesday, 25 November 2009 07:46:43 UTC