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

[whatwg] LocalStorage in workers

From: Jeremy Orlow <jorlow@chromium.org>
Date: Tue, 15 Sep 2009 18:56:44 -0700
Message-ID: <5dd9e5c50909151856j4369b36epada4e230df96304a@mail.gmail.com>
I've talked to a lot of web developers about workers and the one thing that
they keep expressing to me is how disappointing it is to not have access to
LocalStorage.  I tell them about the "work around" which is to pass a
message back to the page (or, in the case of shared workers, any page) and
ask it to look up the value, but this approach is uninteresting to most of
them.  Enough so that most of them have said they'd probably just wait until
workers were more "mature" (and/or WebDatabase was more widely available)
before bothering with them.
The problem is that LocalStorage is a synchronous interface.  When you
access it from a normal web page, all other event loops that try to access
it will block until either you exit your script context or call
yieldForStorageUpdates manually.  Of course, during this time, the UI of the
browser will be locked up and many UAs would present the user with a slow
script dialog.  This is (hopefully) enough to keep web apps reasonably in

Unfortunately, it's perfectly reasonable for a worker to run forever.  For
example, it might calculate pi.  If, for example, that worker periodically
saved the value of pi to localStorage (and didn't call
yieldForStorageUpdates) then you could block your other event loops forever.
 Even if a worker held the lock for a couple hundred milliseconds, it could
still affect the responsiveness of a web browser in a perceivable for no
apparent reason (from the users perspective).  For this reason, it was taken
out of the spec.

One possible solution is to add an asynchronous callback interface for
LocalStorage into workers.  For example:

function myCallback(localStorage) {
  localStorage.accountBalance = localStorage.accountBalance + 100;
executeLocalStorageCallback(myCallback);  // TODO: Make this name better

The interface is simple.  You can only access localStorage via a callback.
 Any use outside of the callback is illegal and would raise an exception.
 The callback would acquire the storage mutex during execution, but the
worker's execution would not block during this time.  Of course, it's still
possible for a poorly behaving worker to do large amounts of computation in
the callback, but hopefully the fact they're executing in a callback makes
the developer more aware of the problem.

I admit that this is not a great solution and would definitely like to hear
alternate proposals.  But, no matter what, I think we need to think
seriously about giving workers access to LocalStorage again.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090915/35ff656d/attachment.htm>
Received on Tuesday, 15 September 2009 18:56:44 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:08:52 UTC