[whatwg] localStorage mutex - a solution?

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
>

Received on Wednesday, 4 November 2009 15:31:36 UTC