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

Re: [chromium-html5] LocalStorage inside Worker

From: Glenn Maynard <glenn@zewt.org>
Date: Wed, 12 Jan 2011 06:14:20 -0500
Message-ID: <AANLkTikgqFTdsmoZCB6Hc-HcOXK5Ha6LuBgJHG9MAeaH@mail.gmail.com>
To: Keean Schupke <keean@fry-it.com>
Cc: Jeremy Orlow <jorlow@chromium.org>, Jonas Sicking <jonas@sicking.cc>, robert@ocallahan.org, Charles Pritchard <chuck@jumis.com>, public-webapps WG <public-webapps@w3.org>
On Wed, Jan 12, 2011 at 6:00 AM, Keean Schupke <keean@fry-it.com> wrote:
> IMHO, if the global lock on localStorage implemented, then I think it is
> acceptable to say localStorage may have poor performance with multiple
> windows/tabs open. If you want better then use IndexedDB.

Performance isn't the problem.  The problems, as I understand them, are:

1: the global lock is simply not being implemented; it's too hard to
implement this sort of locking from within a running UI thread
properly, and
2: unlike scripts in the main thread, a worker thread may not return
to caller regularly; that's when the storage mutex is unlocked, which
means there's no proepr way to unlock the storage mutex from a thread.

The callback API addresses both of these problems.

On 12 January 2011 10:21, Jeremy Orlow <jorlow@chromium.org> wrote:
> Why not just use a small library (like lawnchair) on top of IndexedDB
> instead?  This doesn't seem like it's worth the surface area at all...

This sounds more like an argument for deprecating the entire Storage API.

Glenn Maynard
Received on Wednesday, 12 January 2011 11:14:53 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 11 February 2015 14:36:48 UTC