[whatwg] Storage mutex

[Darin Fisher]

On Wed, Aug 26, 2009 at 1:27 AM, Jeremy Orlow <jorlow at chromium.org> wrote:

> 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?
>

I meant that the current Firefox behavior is technically incorrect.  No one
likes app modal dialogs, but how else can you guarantee run-to-completion
semantics? How else do you prevent other scripts from modifying your state
while you are stuck calling into window.alert().



>
> 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.
>

incrementing a counter on each modification to the database would involve
some broadcasting of notifications to each renderer, or we'd need to store
the counter in shared memory.  either seems unfortunate given the debugging
use case.

if we only record the fact that getStorageUpdates (or equivalent) was
called, then it is just a local boolean in the renderer process.  that seems
substantially simpler to implement without performance penalty.




>
>
>>  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.
>

right, this ^^^ is what i meant.

-darin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090826/f43db576/attachment.htm>