[whatwg] localStorage + worker processes

[Drew Wilson]

The problem is that .length is basically useless without some kind of
immutability guarantees.
I've thought about this more, and I'm afraid that if you start making the
API cumbersome (forcing only async access) then apps are just going to use
document.cookies instead of localStorage. I'd hate to see us radically
change the API to support the worker case - I'd rather get rid of
localStorage support from workers, or else just enforce a max time that a
worker can hold the lock.

-atw

On Sun, Mar 22, 2009 at 10:46 AM, Michael Nordman <michaeln at google.com>wrote:

>
>
> On Sat, Mar 21, 2009 at 3:25 PM, Aaron Boodman <aa at google.com> wrote:
>
>> On Sat, Mar 21, 2009 at 1:51 PM, Jonas Sicking <jonas at sicking.cc> wrote:
>> > The problem with synchronously grabbing the lock is that we can only
>> > ever have one feature that uses synchronous locks, otherwise we'll
>> > risk dead-locks.
>> >
>> > Say that we make document.cookie behave the same way (to prevent
>> > multi-process browsers like IE8 and chrome from having race
>> > conditions). So that if you call document.getCookiesWithLock(callback)
>> > we'll synchronously grab a lock and call the callback function. This
>> > would cause two pages like the ones below to potentially deadlock:
>> >
>> > Page 1:
>> > getLocalStorage(function(storage) {
>> >  document.getCookiesWithLock(function(cookieContainer) {
>> >    storage.foo = cookieContainer.getCookie('cookieName');
>> >  });
>> > ]);
>> >
>> > Page 2:
>> > document.getCookiesWithLock(function(cookieContainer) {
>> >  getLocalStorage(function(storage) {
>> >    cookieContainer.setCookie('cookieName', storage.bar);
>> >  });
>> > });
>>
>> Good point. Ok, I agree that an asynchronous callback makes most sense
>> for this API.
>>
>
> Given an async api, would it be possible to store values into localStorage
> at onunload time? I expect that could be a useful time to use this API.
>
> function onunload() {
>   getLocalStorage(function(storage) {
>     // Will this ever execute?
>   });
> }
>
> Locking the storage until script completion isn't really necessary in many
> cases. Maybe we're over engineering this? Suppose immutability across calls
> was generally not guaranteed by the existing API. And we add an async
> getLocalStorage(callback) which does provide immutability for the duration
> of the callback if that is desired.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090322/5c361ded/attachment.htm>