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 <gl...@zewt.org> wrote: > On Fri, Jan 7, 2011 at 12:30 AM, Felix Halim <felix.ha...@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 > >
