- From: Felix Halim <felix.halim@gmail.com>
- Date: Fri, 7 Jan 2011 13:30:29 +0800
- To: Jonas Sicking <jonas@sicking.cc>
- Cc: Jeremy Orlow <jorlow@chromium.org>, public-webapps WG <public-webapps@w3.org>
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