[whatwg] localStorage, the storage mutex, document.domain, and workers

[Jonas Sicking]

On Thu, Sep 17, 2009 at 10:53 AM, Jeremy Orlow <jorlow at chromium.org> wrote:
> On Thu, Sep 17, 2009 at 1:32 AM, Ian Hickson <ian at hixie.ch> wrote:
>>
>> On Tue, 15 Sep 2009, Jonas Sicking wrote:
>> >
>> > First off, I agree that not having localStorage in workers is a big
>> > problem that we need to address.
>> >
>> > If I were designing the localStorage interface today I would use the
>> > above interface that you suggest. Grabbing localStorage can only be done
>> > asynchronously, and while you're using it, no one else can get a
>> > reference to it. This way there are no race conditions, but also no way
>> > for anyone to have to lock.
>> >
>> > So one solution is to do that in parallel to the current localStorage
>> > interface. Let's say we introduce a 'clientStorage' object. You can only
>> > get a reference to it using a 'getClientStorage' function. This function
>> > is available both to workers and windows. The storage is separate from
>> > localStorage so no need to worry about the 'storage mutex'.
>>
>> I think we should be very careful before introducing a fourth storage
>> mechanism to make sure that whatever we introduce really is something
>> that's going to be very useful and really solve problems. I'd really
>> rather not rush into adding yet another mechanism at this point.
>
> Sure.  But what about the other idea Robert and Drew had (in the workers +
> local storage thread) about just having a WorkerLocalStorage mechanism?
>  Only workers would be able to access it and the interface would be exactly
> the same as LocalStorage.  The only difference is that the data is in
> a separate area (and pages/workers cannot share data).  (Though we could, in
> the future, add such an async interface if we wanted to allow pages to
> access it.)  I know the burden for implementation in WebKit is low, and I
> imagine (though don't know for sure) that the burden would be low in other
> browsers as well.

This is what I think we should do. I do think that an async accessor
in pages would increase its utility significantly. In fact, if we did
that the interface could even work as an alternative to localStorage
on the main thread for applications that worry about the locking, and
thus unresponsive UI, that the storage mutex creates.

/ Jonas