[whatwg] localStorage + worker processes
Jeremy Orlow
jorlow at google.com
Fri Mar 20 13:23:38 PDT 2009
I'm currently implementing window.localStorage (
http://dev.w3.org/html5/webstorage/#storage) in Chromium. While figuring
out how to handle concurrency, the issue of integration with workers came
up. The big problem is that there are many valid/good uses of workers that
could not be used in conjunction with localStorage.
Before I continue, so that this discussion can be focused, let's just assume
that modern day browsers will use the following concurrency model: "the user
agent blocks scripts in other browsing contexts when they try to access the
same storage area until the event loop running the first script has
completed running the task that started that script" (Workers running
within a single event loop makes no sense and I really don't want this to
turn into a debate on the practicality of optimistic transactions. :-)
Anyhow, the very first example in the spec (
http://dev.w3.org/html5/workers/#a-background-number-crunching-worker) shows
work that's being done in a infinite loop with postMessage being called when
each prime is found. If you called localStorage anywhere within that loop
(say, to periodically save all primes found), you would not be able to
safely call window.localStorage in any other worker or the web page. This
is because the "task that started the script" never ends. And this its
'lock' (on other scripts using local storage) will never be released.
That's obviously a somewhat extreme (though I'd argue _not_ contrived)
example, but it seems to me that a lot of the work done in workers will be
fairly long lived. Thus presenting serious latency problems for any page or
other worker trying to access localStorage.
What is the need for localStorage access within workers? Technically if
someone really needed to access it, they could always have a function in the
web page for accessing it and then use postMessage. In other words, they
could build their own ad-hoc async API pretty easily. Another alternative
is to just build an async API into the spec (and remove synchronous access
to localStorage).
Thoughts?
J
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090320/d49fd5bb/attachment.htm>
More information about the whatwg
mailing list