Re: [chromium-html5] LocalStorage inside Worker

On Fri, Jan 7, 2011 at 4:58 PM, Glenn Maynard <glenn@zewt.org> wrote:
> A solution that makes localStorage read-only in workers is no solution.

If the current implementation of localStorage is broken by opening two
tabs, then why not allow workers to access the localStorage already?
As you have mentioned, it is no different than opening several more
tabs. So, assuming the localStorage is consistent even with multiple
tabs open, the remaining problem is dealing with the workers' access.
I fail to see why making a read-only localStorage in workers is "a no
solution"?



Thanks to Keean's pointer, I dug up a short but really helpful STM talk:

http://blip.tv/file/get/OSCON-OSCON2007SimonPeytonJones914.mov

Go back to the multiple tabs problem: if we opened 10 tabs, then the
"interleaving JS" (mentioned by Boris) may degrade the performance by
10 times. In this case, perhaps we need STM (those who use STM will
gain performance, those who don't will fallback to interleaving JS)?



On Fri, Jan 7, 2011 at 5:33 PM, Keean Schupke <keean@fry-it.com> wrote:
> - It solves the efficiency problem

>From the video, I see that while optimistic is good for performance,
in the same way it's bad for performance since it have to keep a log
(for rollback). I believe Jonas' getBetterStorage doesn't need to
maintain a log as it is assumed that it never have to
retry/rollback/fail, but it is executed single-threadedly. Application
specific benchmark is needed... but I believe both will be efficient
enough.


> It also has the following advantages (quoted from the tutorial I posted):
> - No race conditions due to forgotten locks

Race conditions still happen if you (jarringly) forgot to wrap your
"shared" object inside atomic block :P. So, maybe it's a good idea to
only allow localStorage to be accessed inside an atomic block (even in
workers)?


On Fri, Jan 7, 2011 at 5:39 PM, Keean Schupke <keean@fry-it.com> wrote:
>> 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.
>
> How is this any different from having a big loop an any callback:
> var onclick = fuction() {
>    for (i = 0; i < 1000000000; i++) {
>        // do some work
>    }
> }
> I've just made the page non-responsive...
> Also notice:
> atomic(function(state) {...})
> The commit happens automatically when the callback function returns, so a
> split transaction (the commit in a callback) is impossible with this
> formulation. Just think about the lexical-scoping.

An example of a "long transaction" that committed in a callback is:
you are committing based on the return value of an AJAX call... and to
make that AJAX call, you require to be inside atomic block while
reading some shared value...  I know it's a bad example, but it's one
of the idea of the "long transaction" I mentioned. So I guess atomic
doesn't span to a "very long" transaction (it does not necessarily
need to make the browser unresponsive).

But I agree, for short transactions, it looks simple and perfect.

In the video, the proposed atomic is blocking. So, perhaps the
Javascript API needs to supply a callback (for non-blocking) to be
called after the atomic routine is finished?

Felix Halim

Received on Friday, 7 January 2011 17:20:12 UTC