[whatwg] LocalStorage in workers

[Jeremy Orlow]

On Wed, Sep 16, 2009 at 1:06 PM, James Robinson <jamesr at google.com> wrote:

> On Wed, Sep 16, 2009 at 11:34 AM, Michael Nordman <michaeln at google.com>wrote:
>
>>
>>
>> On Wed, Sep 16, 2009 at 11:24 AM, James Robinson <jamesr at google.com>wrote:
>>
>>> On Wed, Sep 16, 2009 at 10:53 AM, Michael Nordman <michaeln at google.com>wrote:
>>>
>>>>
>>>>
>>>> On Wed, Sep 16, 2009 at 9:58 AM, Drew Wilson <atwilson at google.com>wrote:
>>>>
>>>>> Jeremy, what's the use case here - do developers want workers to have
>>>>> access to shared local storage with pages? Or do they just want workers to
>>>>> have access to their own non-shared local storage?
>>>>> Because we could just give workers their own separate
>>>>> WorkerLocalStorage and let them have at it. A worker could block all the
>>>>> other accesses to WorkerLocalStorage within that domain, but so be it - it
>>>>> wouldn't affect page access, and we already had that issue with the (now
>>>>> removed?) synchronous SQL API.
>>>>>
>>>>> I think a much better case can be made for WorkerLocalStorage than for
>>>>> "give workers access to page LocalStorage", and the design issues are much
>>>>> simpler.
>>>>>
>>>>
>>>> Putting workers in their own storage silo doesn't really make much
>>>> sense? Sure it may be simpler for browser vendors, but does that make life
>>>> simpler  for app developers, or just have them scratching their heads about
>>>> how to read/write the same data set from either flavor of context in their
>>>> application?
>>>>
>>>> I see no rhyme or reason for the arbitrary barrier except for browser
>>>> vendors to work around the awkward implict locks on LocalStorage (the source
>>>> of much grief). Consider this... would it make sense to cordon off the
>>>> databases workers vs pages can see? I would think not, and i would hope
>>>> others agree.
>>>>
>>>
>>> The difference is that the database interface is purely asynchronous
>>> whereas storage is synchronous.
>>>
>>
>> Sure... we're talking about adding an async api that allows worker to
>> access a local storage repository... should such a thing exist, why should
>> it not provide access to the same repository as seen by pages?
>>
>
> Not quite - Jeremy proposed giving workers access to a synchronous API
> (localStorage.*) but to only allow it to be called within the context of a
> callback that the UA can run when it chooses.  It's another way to approach
> the implicit locking since a UA would have to, in effect, hold the storage
> mutex for the duration of the callback.  The page's context could still be
> blocked for an indefinite amount of time by a worker thread.
>

Exactly.  And I acknowledged this in my original email.

Unfortunately, I don't have a good solution to the problem.  The only thing
I can think of is some timeout, but these would be inherently racy.  There
are times when the system is under heavy load and _everything_ goes slower.
 I don't see how we could enforce that workers don't keep LocalStorage
locked for long enough that UI threads become affected and still keep
behavior deterministic from the web developers point of view.

That said, IF (and this is a big if) we decide to make localStorage NOT have
any run to completion semantics across event loops and instead add in an
async interface for atomic access to localStorage, then this would work,
however.


> Drew suggested isolating the worker's access to a separate storage 'arena'
> so that there wouldn't be shared, synchronous access between the page
> context and a worker context.  This way the synchronous Storage API can be
> used essentially unchanged without having to deal with the more nasty parts
> of synchronization.
>

Drew, the most important thing to the developers I talked to is that they
need _some_ storage directly accessible to workers.  Many were thinking in
terms of a shared worker syncing and doing the bulk of the processing and
then one or more pages acting as thin clients.  Some of them wanted to use
it like shared memory (i.e. workers syncing and doing some processing and
then storing information in storage; pages then display based on that data).
 This is especially interesting because storage events can be used to
trigger updates to content.

As I think about it, I suppose most of the use cases could actually be
solved by a storage for workers, whether or not pages can also access it.
 If the burden were low, it would be nice to make them accessible though.
 If we did this, keeping some form of storage events would be nice.

Note that most of the developers I talked to thought LocalStorage was not
powerful enough for their needs, but since it's the only API supported by
all the browsers they figured they were stuck with it, so they'd have to
find _some_ way to make it work.

So....maybe it doesn't make sense to spend a lot of effort making
LocalStorage (in some form or another) work in workers.  Maybe we should
instead put our effort into something like WebSimpleDatabase?

J
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090916/0c64eac9/attachment.htm>