[whatwg] Storage mutex

[Drew Wilson]

On Tue, Aug 25, 2009 at 11:51 AM, Jeremy Orlow <jorlow at chromium.org> wrote:

> On Sun, Aug 23, 2009 at 11:33 PM, Robert O'Callahan <robert at ocallahan.org>wrote:
>
>> On Sat, Aug 22, 2009 at 10:22 PM, Jeremy Orlow <jorlow at chromium.org>wrote:
>>
>>> 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.
>>>
>>
>> That behaviour sounds worse than what Firefox currently does, where an
>> alert disables input to all tabs in the window (which is already pretty
>> bad), because it willl make applications in visually unrelated tabs and
>> windows hang.
>>
>
> OK...I guess it makes sense to leave this as is.
>
> One thing I just realized that kind of sucks though:  This makes alert
> based debugging much more difficult.  I guess that's acceptable, though.
>

I'm not sure why, unless you are saying that "alert based debugging while
another document is updating the same database simultaneously", then yeah.
But that seems like an obscure case for alert debugging.

The problem with leaving this up to the UA is it becomes a point of
incompatibility - on one browser, it's safe to put up an alert, on another
it isn't. So if applications have to fall back to the LCD behavior, then we
might as well codify it in the spec, which we have :)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090825/38145ff4/attachment-0002.htm>