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.enn...@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.sha...@gmail.com> wrote:
On Wed, Nov 4, 2009 at 5:51 PM, Rob Ennals <rob.enn...@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
