W3C home > Mailing lists > Public > whatwg@whatwg.org > November 2009

[whatwg] localStorage mutex - a solution?

From: Rob Ennals <rob.ennals@gmail.com>
Date: Wed, 4 Nov 2009 15:31:36 -0800
Message-ID: <7F16695A-3A0A-4C01-8E85-554D403E8EDB@gmail.com>
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

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:18 UTC