Re: LocalStorage inside Worker

I suggest people read about Software Transactional Memory before trying to
re-invent the wheel. Minds immeasurably superior to our own (spoken in the
voice of Richard Burton) have already thought long and hard about this.

- It solves the efficiency problem
- It solves the long transaction problem
- Transactions are composable! (big win)

It also has the following advantages (quoted from the tutorial I posted):

- No race conditions due to forgotten locks
- No deadlocks resulting from inconsistent lock ordering
- No Corruption caused by uncaught exceptions
- No lost wakeups induced by omitted notifications

The API presented to the user is very similar to others proposed, it is the
semantics that are different.


Cheers,
Keean.


On 7 January 2011 09:58, Glenn Maynard <glenn@zewt.org> wrote:

> On Fri, Jan 7, 2011 at 12:30 AM, Felix Halim <felix.halim@gmail.com>
> wrote:
> > 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.
>
> In that case, all current applications are already broken in Chrome.
>
> A solution that makes localStorage read-only in workers is no
> solution.  "Cripple the API" isn't an answer.  I think Jonas's async
> callback approach, modulo the comments I made earlier, is the sanest
> approach suggested so far.  It makes localStorage *fully* accessible
> from workers, and also likely improves the unimplemented-storage-mutex
> situation in Chrome, which exists even without workers.
>
> --
> Glenn Maynard
>
>