[whatwg] localStorage mutex - a solution?

[Rob Ennals]

That version is fine with me.

My reason for using MAY was I thought it would make efficient  
implementation easier. Also, testing when things are being unlocked is  
pretty much impossible for users due to the statistical nature of race  
conditions and shedulers.

But yeah, SHALL is better semantically, if everyone is happy to  
imlement that.



-Rob

On Nov 5, 2009, at 11:06 AM, Scott Hess <shess at google.com> wrote:

> "user agent MAY release" means that people will write code which works
> now, and later the browser vendor will make a change that will break
> their code.  Who is at fault?  We all know that the browser vendor is
> at fault!
>
> Suggest "the user agent SHALL release the storage mutex on any API
> operation /other that a local storage operation/".  The user agent is
> free to do internal optimizations to make things super efficient if
> there's only one local storage op client.  But this means that the web
> developer's practical experience will lead them to the right place.
>
> -scott
>
>
> On Thu, Nov 5, 2009 at 11:16 AM, Jeremy Orlow <jorlow at chromium.org>  
> wrote:
>> This is intriguing.  But what it comes down to is what we consider  
>> an "API
>> operation".  For example, you could define "API operation" to be the
>> existing list of thing that unlock LocalStorage.  Or it could be  
>> defined in
>> a way that Darin Fisher's idea to lock whenever we're about to nest  
>> locking
>> calls would also work.  Or a variety of other things.
>> Does anyone have any ideas on what the exact language for what an  
>> "API
>> operation" might look like?
>>
>> I do have a couple of concerns though:
>> Leaving the language open might not be terribly useful to a typical  
>> web
>> developer since they're not going to read the spec and probably  
>> aren't going
>> to have a very firm idea of whether what they're doing could unlock  
>> storage
>> or not.  Experimentation wouldn't work very well since each  
>> platform could
>> be wildly different (since a lot of possible behaviors fall between  
>> the MAY
>> and the MAY NOT in the proposed spec).
>> Another concern is that the worst case performance aspects of  
>> LocalStorage
>> remain.  I cringe every time I think of one event loop blocking  
>> another.
>>  But I will admit that the average time would be better--especially  
>> if we're
>> unlocking fairly aggressively.
>> I'm interested to hear what others have to say on this proposal.
>> J
>>
>> On Wed, Nov 4, 2009 at 3:31 PM, Rob Ennals <rob.ennals at gmail.com>  
>> wrote:
>>>
>>> Missed out the important final qualifier. Here's take 3:
>>>
>>> "the user agent MUST NOT release the storage mutex between calls  
>>> to local
>>> storage, except that the user agent MAY release the storage mutex  
>>> on any API
>>> operation /other that a local storage oeration/"
>>>
>>> If a local storage op can release the mutex then the whole thing is
>>> pointless :-)
>>>
>>> -Rob
>>>
>>> On Nov 4, 2009, at 3:15 PM, Rob Ennals <rob.ennals at gmail.com> wrote:
>>>
>>>> I suspect my suggested spec line was insufficiently precise. How  
>>>> about
>>>> this:
>>>>
>>>> "the user agent MUST NOT release the storage mutex between calls  
>>>> to local
>>>> storage, except that the user agent MAY release the storage mutex  
>>>> on any API
>>>> operation"
>>>>
>>>> We'd still need to define what "API operation" means, and I'm  
>>>> sure this
>>>> could be worded better, but hopefully this makes the basic idea  
>>>> clearer.
>>>>
>>>> -Rob
>>>>
>>>> On Nov 4, 2009, at 2:56 PM, Mike Shaver <mike.shaver at gmail.com>  
>>>> wrote:
>>>>
>>>>> On Wed, Nov 4, 2009 at 5:51 PM, Rob Ennals  
>>>>> <rob.ennals at gmail.com> wrote:
>>>>>>
>>>>>> Or to put it another way: if the thread can't call an API then  
>>>>>> it can't
>>>>>> block waiting for another storage mutex, thus deadlock can't  
>>>>>> occur,
>>>>>> thus we
>>>>>> don't need to release the storage mutex.
>>>>>
>>>>> Right, but the spec text there doesn't prevent the UA from  
>>>>> releasing
>>>>> more than in that scenario, which seems like it's not an  
>>>>> improvement
>>>>> over where we are right now: unpredictable consistency.   
>>>>> Existing racy
>>>>> implementations like in IE would be conformant, so developers  
>>>>> can't
>>>>> count on the script-sequenced-storage-ops pattern providing
>>>>> transactionality.
>>>>>
>>>>> More likely, though, _I_'m missing something...
>>>>>
>>>>> Mike
>>>>
>>
>>