[whatwg] Storage mutex

[Jeremy Orlow]

On Tue, Aug 18, 2009 at 4:26 PM, Jeremy Orlow <jorlow at chromium.org> wrote:

> It's also worth noting that Chromium is probably going to need to drop the
> storage mutex for most if not all plugin related calls due to deadlock
> conditions.  If there were some place to mention this as a "may" type thing,
> it'd be good, but I realize it's probably out of scope for HTML 5.
>

Oops.  The spec already does specify this behavior:
http://dev.w3.org/html5/spec/Overview.html#storage-mutex


On Sat, Aug 22, 2009 at 5:54 AM, Robert O'Callahan <robert at ocallahan.org>wrote:

> On Wed, Aug 19, 2009 at 11:26 AM, Jeremy Orlow <jorlow at chromium.org>wrote:
>
>> First of all, I was wondering why all user prompts are specified as "must
>> release the storage mutex" (
>> http://dev.w3.org/html5/spec/Overview.html#user-prompts).  Should this
>> really say "must" instead of "may"?  IIRC (I couldn't find the original
>> thread, unfortunately) this was added because of deadlock concerns.  It
>> seems like there might be some UA implementation specific ways this could
>> deadlock and there is the question of whether we'd want an alert() while
>> holding the lock to block other execution requiring the lock, but I don't
>> see why the language should be "must".  For Chromium, I don't think we'll
>> need to release the lock for any of these, unless there's some
>> deadlock scenario I'm missing here.
>
>
> So if one page grabs the lock and then does an alert(), and another page in
> the same domain tries to get the lock, you're going to let the latter page
> hang until the user dismisses the alert in the first page?
>

Yes.  And I agree this is sub-optimal, but shouldn't it be left up to the
UAs what to do?  I feel like this is somewhat of an odd case to begin with
since alerts lock up most (all?) browsers to a varying degrees even without
using localStorage.


> Given that different UAs are probably going to have other scenarios where
>> they have to drop the lock (some of them may even be purely implementational
>> issues), should we add some way for us to notify scripts the lock was
>> dropped?  A normal event isn't going to be of much use, since it'll fire
>> after the scripts execution ends (so the lock would have been dropped by
>> then anyway).  A boolean doesn't seem super useful, but it's better than
>> nothing and could help debugging.  Maybe fire an exception?  Are there other
>> options?
>>
>
> A generation counter might be useful.
>

Ooo, I like that idea.  When would the counter increment?  It'd be nice if
it didn't increment if the page did something synchronous but no one else
took the lock in the mean time.


>  Lastly, is navigator.getStorageUpdates() the right name for the function
>> that drops the lock?  Why was it changed from navigator.releaseLock()?  I
>> assume we're trying to avoid the word "lock", but the reason why you'd need
>> to call a function to get updates is not clear without understanding the
>> concept of a lock...so what's the point of making this so cryptic?
>>
>
> Authors would be confused that there's no aquireLock() API.
>

Good point.

But getStorageUpdates is still not the right name for it.  The only way that
there'd be any updates to get is if, when you call the function, someone
else takes the lock and makes some updates.  Maybe it should be yieldStorage
(or yieldStorageMutex)?  In other words, maybe the name should imply that
you're allowing concurrent updates to happen?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090822/0a1d5cb7/attachment-0002.htm>