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

[whatwg] localStorage + worker processes

From: Robert O'Callahan <robert@ocallahan.org>
Date: Mon, 23 Mar 2009 12:27:56 +1300
Message-ID: <11e306600903221627o3543ac1apac233a3b8d426396@mail.gmail.com>
On Mon, Mar 23, 2009 at 8:07 AM, Michael Nordman <michaeln at google.com>wrote:

> I don't see how denying workers solves the problem. In a multi-threaded
> browser, this has to be resolved reasonably even in the absence of workers.
>

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

If IE7+ allows asynchronous cookie changes, that is a bad bug. Perhaps today
they get away with it because people aren't writing long-running scripts
that use cookies as read/write storage. We shouldn't take that as a sign
that the shared-state threaded programming model somehow works better on the
Web than it does everywhere else.

Some sort of implicit locking with guaranteed deadlock freedom should be
workable for parallel browser implementations. For example, partition
browser contexts into "related" subsets, where context A is related to
context B if a script running in context A can affect the execution of an
already-running script in context B. Use one lock per subset, and have a
script execution acquire the lock when it first touches localStorage or
cookies, and drop the lock when it completes (or yields). Additional
optimizations are possible.

An asynchronous API like the multi-resource-acquisition callback Jonas just
proposed, would be helpful to enable additional parallelism. By declaring
up-front which resources need to be locked and guaranteeing that only those
resources will be touched, you can use a finer-grained locking scheme
without risking deadlock.

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/20090323/dc5723c5/attachment.htm>
Received on Sunday, 22 March 2009 16:27:56 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 30 January 2013 18:47:49 GMT