W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2011

Re: [chromium-html5] LocalStorage inside Worker

From: Keean Schupke <keean@fry-it.com>
Date: Sat, 8 Jan 2011 12:14:21 +0000
Message-ID: <AANLkTi=17vZ3JwocTud5uP4EP9pU0ry4MnGusb7DOXBE@mail.gmail.com>
To: Glenn Maynard <glenn@zewt.org>
Cc: Charles Pritchard <chuck@jumis.com>, Jonas Sicking <jonas@sicking.cc>, public-webapps WG <public-webapps@w3.org>
On 8 January 2011 11:45, Glenn Maynard <glenn@zewt.org> wrote:

> On Sat, Jan 8, 2011 at 6:10 AM, Keean Schupke <keean@fry-it.com> wrote:
> > I am suggesting that as the semantics are the same, People can think of
> this
> > like serialised access, but implementers can use STMs to make their
> browser
> > faster than the competition (if they want). To the user it will look the
> > same.
> Not according to [1].  By the description there, STM requires
> re-executing the callback if two callbacks simultaneously modify the
> same data and cause a conflict.  This is very different to the user,
> who has to deal with the possibility of the callback being called
> multiple times.  Any side-effects of the function would occur multiple
> times.  This would lead to many subtle bugs, because the retry case
> would be exceedingly rare, causing very poorly-tested code paths in
> user code.  It's also much more complex to spec, and for users to
> understand.
> Jonas's approach behaves like any other callback, being called just once.

> [1]
> http://book.realworldhaskell.org/read/software-transactional-memory.html
> --
> Glenn Maynard

Yes, you are right, side effects in JavaScript are a problem. It makes no
difference in Haskell, because side effects are tightly controlled.

That seems to make serialising them the simplest and easiest to use option.
It's not scalable of course - but that seems to be a low priority here.

Received on Saturday, 8 January 2011 12:14:54 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:29 UTC