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: Tue, 11 Jan 2011 22:11:42 +0000
Message-ID: <AANLkTimcBMqXM0eSr6j0A1EEstt62bQ5xf3OfsdtSe9j@mail.gmail.com>
To: Jonas Sicking <jonas@sicking.cc>
Cc: Jeremy Orlow <jorlow@chromium.org>, robert@ocallahan.org, Glenn Maynard <glenn@zewt.org>, Charles Pritchard <chuck@jumis.com>, public-webapps WG <public-webapps@w3.org>
Would each 'name' storage have its own thread to improve parallelism?


would:

withNamedStorage('x', function(store) {...});

make more sense from a naming point of view?


Cheers,
Keean.


On 11 January 2011 20:58, Jonas Sicking <jonas@sicking.cc> wrote:

> With localStorage being the way it is, I personally don't think we can
> ever allow localStorage access in workers.
>
> However I do think we can and should provide access to a separate
> storage area (or several named storage areas) which can only be
> accessed from callbacks. On the main thread those callbacks would be
> asynchronous. In workers those callbacks can be either synchronous or
> asynchronous. Here is the API I'm proposing:
>
> getNamedStorage(in DOMString name, in Function callback);
> getNamedStorageSync(in DOMString name, in Function callback);
>
> The latter is only available in workers. The former is available in
> both workers and in windows. When the callback is called it's given a
> reference to the Storage object which has the exact same API as
> localStorage does.
>
> Also, you're not allowed to nest getNamedStorageSync and/or
> IDBDatabaseSync.transaction calls.
>
> This has the added advantage that it's much more implementable without
> threading hazards than localStorage already is.
>
> / Jonas
>
> On Tue, Jan 11, 2011 at 6:40 AM, Jeremy Orlow <jorlow@chromium.org> wrote:
> > So what's the plan for localStorage in workers?
> > J
> >
> > On Tue, Jan 11, 2011 at 9:10 AM, Keean Schupke <keean@fry-it.com> wrote:
> >>
> >> I think I already came to the same conclusion... JavaScript has no
> control
> >> over effects, which devalues STM. In the absence of effect control,
> apparent
> >> serialisation (of transactions) is the best you can do.
> >> What we need is a purely functional JavaScript, it makes threading so
> much
> >> easier ;-)
> >>
> >> Cheers,
> >> Keean.
> >>
> >> On 10 January 2011 23:42, Robert O'Callahan <robert@ocallahan.org>
> wrote:
> >>>
> >>> STM is not a panacea. Read
> >>>
> http://www.bluebytesoftware.com/blog/2010/01/03/ABriefRetrospectiveOnTransactionalMemory.aspx
> >>> if you haven't already.
> >>>
> >>> In Haskell, where you have powerful control over effects, it may work
> >>> well, but Javascript isn't anything like that.
> >>>
> >>> Rob
> >>> --
> >>> "Now the Bereans were of more noble character than the Thessalonians,
> for
> >>> they received the message with great eagerness and examined the
> Scriptures
> >>> every day to see if what Paul said was true." [Acts 17:11]
> >>
> >
> >
>
Received on Tuesday, 11 January 2011 22:12:18 GMT

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