[whatwg] localStorage + worker processes

[Michael Nordman]

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/497ba69d/attachment.htm>