[whatwg] localStorage mutex - a solution?
rob.ennals at gmail.com
Wed Nov 4 15:31:36 PST 2009
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
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
> 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>
>>> Or to put it another way: if the thread can't call an API then it
>>> 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
>> implementations like in IE would be conformant, so developers can't
>> count on the script-sequenced-storage-ops pattern providing
>> More likely, though, _I_'m missing something...
More information about the whatwg