On Thu, Sep 17, 2009 at 1:32 AM, Ian Hickson <i...@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.