[whatwg] Storage mutex

[Jeremy Orlow]

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.


>  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.
>>
>
> Defining "no-one else" may be difficult. I haven't thought this through, to
> be honest, but I think you could update the counter every time the storage
> mutex is released and the shared state was modified since the storage mutex
> was acquired. Reading the counter would acquire the storage mutex. You'd
> basically write
>
> var counter = window.storageMutexGenerationCounter;
> ... do lots of stuff ...
> if (window.storageMutexGenerationCounter != counter) {
>   // abort, or refresh local state, or something
> }
>
> I'm not sure what you'd do if you discovered an undesired lock-drop,
> though. If you can't write something sensible instead of "abort, or
> something", it's not worth doing.
>

I guess it would depend on the use.  Let's say a library/framework dependeds
on the lock being held but does a callback (that might do something that
causes the lock to be dropped).  It could check the counter and raise an
exception.  It could also re-start "processing" if that were an acceptable
answer (but by having the counter, it would only do so when necessary).  I
think it'll be very application specific _what_ you do when you catch such
an error, but I do think it'll be valuable to developers.


>  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?
>>
>
> I thought that's what getStorageUpdates implied :-).


To me, getStorageUpdates seems to imply that updates have already happened
and we're working with an old version of the data.  I think many developers
will be quite shocked that getStorageUpdates _enables_ others to update
storage.  In other words, 'get' seems to imply that you're consuming state
that's happening anyway, not affecting behavior.

For what it's worth, I sanity checked my point with a web developer here at
Google working with LocalStorage and he too thought the name was
misleading/not clear.  Are we the only ones??
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090825/144d7349/attachment-0001.htm>