Re: [chromium-html5] LocalStorage inside Worker

On Tue, Jan 11, 2011 at 3:58 PM, Jonas Sicking <jonas@sicking.cc> wrote:
> With localStorage being the way it is, I personally don't think we can
> ever allow localStorage access in workers.

This makes sense if the storage mutex goes away entirely for
localStorage itself (reflecting current implementations).

If localStorage retains the current unimplemented locking, then it
makes sense to use the same Storage for both APIs.  The async callback
would use the same storage mutex, so a fully compliant implementation
would be threadsafe.

Removing it makes sense to me, though.

> However I do think we can and should provide access to a separate
> storage area (or several named storage areas) which can only be
> accessed from callbacks. On the main thread those callbacks would be
> asynchronous. In workers those callbacks can be either synchronous or
> asynchronous. Here is the API I'm proposing:
>
> getNamedStorage(in DOMString name, in Function callback);
> getNamedStorageSync(in DOMString name, in Function callback);

I guess to determine whether a particular named storage is supported,
you'd call it with the name and an empty callback; if the name isn't
supported, it raises an exception.  A little awkward, but reasonable.

Maybe the specs guarantee this in general for async callbacks, but
getNamedStorage should never run callback immediately before
returning, even if the lock is available; always wait for the script
to return, as if the lock was taken.

> The latter is only available in workers. The former is available in
> both workers and in windows. When the callback is called it's given a
> reference to the Storage object which has the exact same API as
> localStorage does.

StorageEvent would need an additional attribute, containing the name
associated with the storageArea it's been given.  That's because you
can no longer say eg. "event.storageArea == window.localStorage" to
determine which Storage triggered the event.  Other than that, the
storage event is straightforward; when called during a storage
callback, it has access to the locked Storage object via storageArea.

> Also, you're not allowed to nest getNamedStorageSync and/or
> IDBDatabaseSync.transaction calls.

If a single mutex is used for all storage objects, then nesting
getNamedStorageSync with itself is safe.

If separate mutexes are used for each storage object, then it's still
okay to nest getNamedStorageSync calls to the same object.

This essentially makes it act like a recursive mutex, which can be
very convenient.  It reduces how much a function has to care about its
caller; your Javascript function doesn't need to specify "must not be
called from a getNamedStorageSync callback" if it uses that function
itself.

One other thing to consider: releasing the Storage object and
continuing execution.  The minimum delays imposed on timers makes
setTimeout(continueFunction, 0) a poor solution.

On Tue, Jan 11, 2011 at 5:11 PM, Keean Schupke <keean@fry-it.com> wrote:
> Would each 'name' storage have its own thread to improve parallelism?

Callbacks would execute in the thread they were queued from, not in a
separate thread, if that's what you mean.

-- 
Glenn Maynard

Received on Tuesday, 11 January 2011 23:07:15 UTC