[whatwg] Storage mutex

On Wed, Aug 26, 2009 at 12:51 AM, Darin Fisher <darin at chromium.org> wrote:

> On Sun, Aug 23, 2009 at 11:33 PM, Robert O'Callahan <robert at ocallahan.org>wrote:
>
>> 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.
>>
>
> You can have script connections that span multiple tabs in multiple
> windows, so in order to preserve the run-to-completion semantics of
> JavaScript, it is important that
> window.{alert,confirm,prompt,showModalDialog} be modal across all windows in
> the browser.  This is why those APIs suck rocks, and we should never create
> APIs like them again.
>

I don't understand your point here.  Are you saying that the current firefox
behavior is not correct, that releasing the storage lock on these events is
not correct, or something else?

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.
>>
>
> Implementation-wise, the easiest thing to support is a boolean that becomes
> true when the lock is release and false when the lock is acquired.  Trying
> to update a counter based on modifications to the local storage backend
> which may be happening on another thread seems like more effort than it is
> worth.
>

Such a boolean could be useful, but I disagree with the assertion that the
implementation is significantly more difficult.  I'm pretty sure both would
be trivial in Chromium, for example.


>  But, what would you call this boolean?  storageMayHaveBeenUpdated? :-P
>
> I'm struggling to find a good use case for this.
>

None of the ones I already listed seemed interesting?  If nothing else, I
would think debugability would be a key one.  If we're going to do something
halfway magical, we should make it possible for developers to know it
happened, right??

The getStorageUpdates name seems pretty decent to me when considering it
> from the perspective of the caller.  The caller is saying that they are OK
> with being able to see changes made to the localStorage by "other threads."
>  This cleverly avoids the need to talk about locks, which seems like a good
> thing.  It is okay for there to be no updates to storage.
>

So the use case I've had in my mind that maybe isn't clear is this:

localStorage.getItem/setItem
navigator.getStorageUpdates()
localStorage.getItem/setItem

In other words, no "processing" or anything between calls.

If the act of calling getStorageUpdates gives the lock to everyone who's
waiting for it before letting the caller get it again, then I guess I can
buy this argument.  I still think yieldStorageMutex (or just about anything
for that matter) would be a much better name, but given that no one's
agreeing with me (on this list, anyhow) I'm just going to drop it.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090826/ccbd3afa/attachment.htm>

Received on Wednesday, 26 August 2009 01:27:45 UTC