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: Fri, 7 Jan 2011 11:00:25 +0000
Message-ID: <AANLkTi=3Vw79H30-iRTwRcPoo6aOt6onpuqa38K9T3dW@mail.gmail.com>
To: Jonas Sicking <jonas@sicking.cc>
Cc: Felix Halim <felix.halim@gmail.com>, Jeremy Orlow <jorlow@chromium.org>, public-webapps WG <public-webapps@w3.org>
>
>
> 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.
>
> / Jonas
>
>
This is true, serialising access would have the same semantics as STM.
Infact you could consider STM to be a performance enhancement to sequential
access by optimistically allowing concurrent modifications and only doing
something special if there is a collision (a read from a location written by
another thread during the transaction). In which case STM works like a
database and rolls back the transaction. It is really putting a thread local
"log" between the user and the storage. The main storage is then only locked
during the log commit, reducing resource contention. A rollback is simply
discarding the log.

But this would behave identically (apart from the extra features in STM like
guards and retry) to serialisation of requests.

A simple (non STM) implementation would be to have a single thread
associated with the localStorage and require all accesses to be executed by
that thread (in callbacks). You could use the main UI thread, but it would
make worker threads wait for storage access during DOM processing in
callbacks etc...


Cheers,
Keean.
Received on Friday, 7 January 2011 11:00:58 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:42 GMT