Re: [chromium-html5] LocalStorage inside Worker

So, it may be acceptable to say you can't use localStorage from a worker,
use IndexedDB instead. But is it acceptable to leave localStorage broken
with multiple tabs/windows.  As the spec says there should be a global lock,
that seems to be an implementation problem though.


Cheers,
Keean.


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

> On Wed, Jan 12, 2011 at 11:14 AM, Glenn Maynard <glenn@zewt.org> wrote:
>
>> 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.
>>
>
> It is, but the thing with the web platform is that once you add something
> you can pretty much never remove it.
>
> But I'll be doing everything in my power to push people away from
> LocalStorage once IndexedDB is a bit more mature.
>
> J
>