[whatwg] Storage mutex
Jeremy Orlow
jorlow at chromium.org
Tue Aug 25 11:51:54 PDT 2009
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.htm>
More information about the whatwg
mailing list