[whatwg] localStorage + worker processes

[Robert O'Callahan]

On Tue, Mar 24, 2009 at 10:11 PM, Ian Hickson <ian at hixie.ch> wrote:

>   - extended the implicit lock mechanism that we had for storage to also
>   cover document.cookie, and made the language more explicit about how
>   it works.


That's basically good. It's possible that people might want to implement
something that's equivalent to the storage mutex in observable behaviour,
but allows more parallelism, such as speculative execution or finer-grained
locking when the implementation can prove it's safe. I assume implementors
of HTML5 already understand that that's allowed.

- added navigator.releaseLock().
>

This name could be confusing to developers, because there is no
corresponding explicit acquireLock(), which there usually is in an API that
exposes releaseLock().

navigator.allowInterruption() maybe?

On Sat, 21 Mar 2009, Jonas Sicking wrote:
> >
> > As a side note, if we do go with this async lock acquiring, we could add
> > an API like:
> >
> > getLockedFeatures(callback, 'localStore', 'cookie');
> >
> > This would be an asynchronously grab locks to multiple features and only
> > call the callback once all of them have been acquired. This would allow
> > computations across data from multiple locations guaranteed to be in
> > sync. The implementation would be responsible for grabbing the locks in
> > a consistent order to prevent deadlocks.
>
> Why would we want more than one lock? Is the potential performance gain
> worth the complexity?
>
> The problem with going with an async approach is that it means changing
> the API, which is something we can't really do for cookie (and don't
> really want to do for localStorage, since IE8 has shipped it.) We we are
> going to need a synchronous locking mechanism anyway.


It would be possible to use something like getLockedFeatures for workers
while using implicit locking for the main thread.

On Mon, 23 Mar 2009, Robert O'Callahan wrote:
> > It has to be resolved in a way that doesn't expose asynchronous cookie
> > or localStorage changes to Web developers. There is abundant evidence
> > that race conditions and synchronization are too hard for developers to
> > deal with. The spec should forbid asynchronously visible changes to
> > cookies or localStorage. In fact, it should probably simply say that all
> > script execution is serializable: always equivalent to some execution
> > you could get with a single-threaded browser that runs all scripts to
> > completion. Allowance could be made for explicit yield points if we need
> > to, e.g. alert().
>
> Generally speaking I have tried to maintain this invariant, but I have
> failed with cookies, and with localStorage in workers.


Now, with the storage mutex, are there any cases you know of where
serializability fails? If there are, it may be worth noting them in the
spec. If there aren't, why not simply write serializability into the spec?

User agents that share event loops between origins can't actually have any
> more than one lock total. Consider a case where there are three windows
> from three different origins, A, B, and C, where C contains a couple of
> <iframe>s, and where A, B, and C are independent, but C share an event
> loop with whatever content is in its iframes. (This is the situation
> Chrome and IE are in, as I understand it, with event loops being
> per-window not per-origin, and it may be required because access to the
> frames[] hierarchy is synchronous.) Now, assume A and B have both obtained
> their respective locks, and are busy doing some long script. C is free to
> run more tasks from its event loop, which could include navigating one
> iframe to a page on either A and the other iframe to a page on B, meaning
> that the event loop of C is now beholden to two locks. If there is any
> manner in which to synchronously cause another origin to run script, this
> now means that C can attempt to obtain both locks; if we now imagine
> another window just like C that instead obtains the locks in the reverse
> order, we get deadlock.


Interesting example!

When two sets of unrelated browser contexts become related (e.g., C loads A
into an iframe), I imagined you would join A's lock and C's lock into a
single lock covering the new set of related browser contexts, which is safe
to do if at most one of those locks is currently held. When this happens due
to a document being created with origin A in C's iframe, it happens
asynchronously in C, right? So at that point C's lock is not held by
currently running script in C (although it might be held by code in another
domain which is already related to C), and we can block the join operation
in C until one of the two locks is released.

Then in your example, suppose C loads A's document first. Then C's lock and
A's lock are joined to make a CA-lock. Then suppose D ("another window just
like C") loads B's document; D's lock and B's lock are merged to make the
DB-lock. Now suppose C loads B. The two remaining locks are merged to form a
single CADB-lock. No deadlock is possible.

If it can be shown that it is not ever possible for script in one origin
> to synchronously invoke script in another origin, then I guess we could
> have per-origin locks instead of a single lock.
>

I'm not sure why synchronous invocation across origins matters. I think what
matters here is whether there's a synchronous operation that can cause two
browsing contexts to become related that previously weren't. If there is,
then the above approach would break down; a script in A could get A's lock
and then attempt to join with C, while a script in C could get C's lock and
then attempt to join with A. I can't think of such a case though.

Rob
-- 
"He was pierced for our transgressions, he was crushed for our iniquities;
the punishment that brought us peace was upon him, and by his wounds we are
healed. We all, like sheep, have gone astray, each of us has turned to his
own way; and the LORD has laid on him the iniquity of us all." [Isaiah
53:5-6]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090324/4618da02/attachment-0002.htm>