Re: LocalStorage inside Worker

On Friday, January 7, 2011, Jonas Sicking <jonas@sicking.cc> wrote:
> On Thu, Jan 6, 2011 at 7:37 PM, Felix Halim <felix.halim@gmail.com> wrote:
>> On Fri, Jan 7, 2011 at 6:11 AM, Jonas Sicking <jonas@sicking.cc> wrote:
>>>> On Sat, Jan 1, 2011 at 4:22 AM, Felix Halim <felix.halim@gmail.com> wrote:
>>>>> 5: Why not make localStorage accessible from the Workers as "read only" ?
>>>
>>> Unfortunately this is not possible. Since localStorage is
>>> synchronously accessed, if we allowed workers to access it that would
>>> mean that we no longer have a shared-nothing-message-passing threading
>>> model. Instead we'd have a shared memory threading model which would
>>> require locks, mutexes, etc.
>>
>> What I was suggesting as "read only" is like a "snapshot". So, when
>> the main html page spawn a worker, a (consistent) snapshot of the
>> localStorage is build at that point of time and passed on to the
>> worker. This is the same as creating a worker and sending the first
>> message to it (which is the localStorage content, but the difference
>> is the snapshot can be more efficient for the main page thread I
>> believe).
>
> Ah, that changes things completely! Thanks for clarifying that.
>
> What is the usecase for this?

The best use case is:

Set the data once, read many times.



> This is potentially fairly high overhead implementation-wise and so
> could slow down localStorage. But I agree it doesn't have the raciness
> problems that other suggested solutions have had.

No, it is at least as efficient as the message passing.


> Consider for example the following events:
>
> 1. A site stores a 1 MB value in localStorage.foo.
> 2. The site creates a new worker.
> 3. The site modifies the value in localStorage.foo to a different 1MB value.
>
> At this point, even the best implementation will have to keep both the
> new and the old value in localStorage. Despite the worker not even
> using localStorage and thus doesn't care about the old value. It's
> certainly implementable, but it'll waste resources.

If you do it via message passing to the workers, isn't it the same
overhead? The worker will have the old 1 MB value until the message
comes and replaces it with the new 1 MB.

If the worker doesn't listen to changes, you don't need to bother
updating it. The listener can be made more fine grained by listening
to specific key only.

See my initial proposal on the benefits. The read only localStorage
shines when you have multiple workers reading it. In the message
passing way, this is inefficient as the 1MB get send multiple times,
and blocking the main page thread. Using read only localStorage, no
message are sent, since it's already sitting there, and you only need
two copies at most.

Of course a smart developer wont change 1MB too often and may want to
consider breaking it into multiple keys with smaller values.

>>> That said. As I have suggested before (don't remember if it was here
>>> or on the whatwg list), if we create a new version of localStorage,
>>> where you can only get a reference to the localStorage object
>>> asynchronously, then we should be fine. So something like:
>>>
>>> var s;
>>> getBetterStorage(function(storage) {
>>>  storage.foo += storage.bar;
>>>  storage.baz = "hello world";
>>>  storage.text = "she sells sea schells by the sea shore";
>>>  s = storage;
>>>  setTimeout("runlater", 10);
>>> });
>>
>> Allowing localStorage to be modified inside worker is not safe!
>
> Note that the above intentionally doesn't use localStorage! But rather
> a different Storage object which can only be accessed asynchronously
> and which doesn't overlap with localStorage.

Ok. But what i'm trying to say is, forcing the localStorage to use
"atomic" block is a bad idea in the main page thread since a
transaction in the main page thread can span very long time perhaps
committed by a click event.

>
> So long as you only allow asynchronous access the implementation can
> ensure that a worker and the main thread doesn't have access to the
> storage at the same time. Then it is safe to allow everyone to modify
> the storage area.
>

Yes, i agree, but i feel that localStorage will be too confusing if
used asynchronously for the long transaction reason above.

The usage of localStorage in the main page thread is much uglier than
any spaghetti code. Any callback could update it. Currently, everybody
uses the localStorage in synchronous mode in the main page thread and
assumes no other theads can modify it. Allowing workers to change its
value (even in atomic asynchronous mode) will breaks all current
applications.

Felix Halim

-- 
Felix Halim

Received on Friday, 7 January 2011 08:03:26 UTC