[whatwg] RFC: Alternatives to storage mutex for cookies and localStorage

[Jeremy Orlow]

On Tue, Sep 8, 2009 at 5:54 PM, Aaron Boodman <aa at google.com> wrote:
>
>  > You'd have to implement it via a mutex.
>
> I think you would have a queue of all pending requests for access to
> storage, along with their associated callbacks, message loops, and
> execution environments. Each time the local storage frees up, if there
> is any queued request, invoke the callback in the correct environment.


I guess I should have said "mutex" (in quotes) because something like this
is what I intended.

Not that it matters to the spec, but this is more or less how I'm
implementing locking within Chromium.  The only difference is that the queue
is of renderer processes (blocked on getting the lock) rather than
individual callbacks.  Doing the latter would be nice since sometimes web
pages have to share the same process (and thus one origin may block another
from executing because of Chromium implementational details).

> An optimized implementation could
> > wait until the first operation that can't be un-done before acquiring it,
> > and do everything optimistically until then.  This is the same situation
> as
> > WebDatabase if I understand it correctly.
>
> You can't do this because upgrading the lock could block the UI
> thread. Same thing with the database spec.
>

Sure you could block the UI thread more, but there's nothing to stop you
from doing a 'while (true) { }' inside the callback, which will block the UI
thread as well.  So I disagree with your assertion that waiting for a lock
upgrade is a deal breaker.  I don't think any implementation is
realistically going to do anything like this in the near term, though.

If you want to get fancy, the transaction() method can take a
> read/write param. This is what the database spec does, but I think it
> is overkill here, personally.


Agreed.


On Tue, Sep 8, 2009 at 6:02 PM, Robert O'Callahan <robert at ocallahan.org>
 wrote:

> On Tue, Sep 8, 2009 at 8:38 PM, Jeremy Orlow <jorlow at chromium.org> wrote:
>
>> To be clear, Chrome is not going to implement the storage mutex with
>> respect to cookies, but we are going to implement it for LocalStorage.
>>  Because of this, we can handle the localStorage mutex on a per-origin basis
>> (which I'm implementing right now).
>>
>
> Looking back over previous threads on the storage mutex, I can't seem to
> remember or find the reason that implementing the storage mutex for cookies
> can't easily be done with a mutex per domain. Ian pointed out this approach
> breaks if you can make synchronous script calls across origins (e.g. across
> IFRAME boundaries), but can you actually make such calls? Or if you can
> (NPAPI?), can we just declare that those APIs release the storage mutex?
>

I thought it over, but I can't come up with any deadlock scenario.  I would
still be a bit worried about performance issues (including many ways a
developer could shoot themself in the foot), but it is an interesting idea.


> I know that setting document.domain makes this tricky because it
> synchronously enables new cross-domain interactions, but can't we handle
> that by declaring that setting document.domain releases the storage mutex?


I think this would be very reasonable.  Especially with all the other things
that already implicitly drop the lock.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090908/d38c5d93/attachment-0002.htm>