[whatwg] localStorage feedback

On Wed, Dec 2, 2009 at 2:06 AM, Ian Hickson <ian at hixie.ch> wrote:

> On Tue, 3 Nov 2009, Jeremy Orlow wrote:
> >
> > If we do this, we need to re-visit ways that scripts can tell whether
> > the lock has been dropped.  I can't remember which idea was most in
> > favor last time we talked about it, but a counter that increments every
> > time LocalStorage is unlocked sticks out in my mind.  (Scripts can check
> > the counter, do something that could cause unlocking, and then verify
> > the counter is still the same after.)
>
> The counter could be a boolean -- does the event loop have the lock [for
> the origin of the first script]. I would recommend implementing this as
> a property window.navigator.webkitStorageUpdatesLocked which is true when
> the lock is obtained and false when it is released. If people find it
> useful, we can add it to the language.
>

If it's a boolean, it's possible that it was implicitly unlocked and then
re-locked.  If you have a counter, you can simply check that the count is
the same as when you started.


> > Another option that just came to mind is to have some flag that says
> > "throw an exception whenever there's been a serialization violation".
>
> Could you elaborate on this?
>

You'd have some boolean property that defaults to false (say
navigator.throwOnStorageMutexDeadlocks) that when set to true would cause an
exception to be thrown either immediately or the next time you try to do a
localStorage operation before either calling
navigator.yieldForStorageUpdates or the task ending.


On Wed, 25 Nov 2009, Jeremy Orlow wrote:
> >
> > 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.
>
> As far as I can tell, this wouldn't remove race problems. It would in fact
> make it impossible to avoid them, since as far as I can tell you can't
> build a sane locking mechanism based on the above.
>

I don't understand what you mean by building a sane locking mechanism.

The idea is that we'd have near-run-to-completion semantics when using local
storage normally (via repeatable reads semantics on localStorage and
document.cookie) and actual run-to-completion semantics (serializable) if
you use the callback based mechanism for localStorage access.

Given that network based cookie access is essentially repeatable read
semantics and both cookie and localStorage in IE and Chrome aren't even that
currently, I'd say that such semantics seem good enough.  The fact that
Chrome has never gotten any complaints about the racy behavior of its
current document.cookie implementation is some evidence to support that.

J
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20091202/63ad33c8/attachment.htm>

Received on Wednesday, 2 December 2009 02:31:16 UTC