Re: [chromium-html5] LocalStorage inside Worker

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.


Cheers,
Keean.

On 12 January 2011 10:21, Jeremy Orlow <jorlow@chromium.org> wrote:

> On Tue, Jan 11, 2011 at 8:58 PM, 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.
>
>
> So basically you want to create yet another storage API?  Didn't we decide
> a while ago this was a bad idea?
>
> 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...
>
>
>> 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]
>> >>
>> >
>> >
>>
>
>