By "API operation" I mean anything other than core ecmascript and
localstorage itself.
Eg you can be sure that the following will not release the mutex:
* do nothing
* function call
* if/for etc
* access to a local variable
* access to a basic ecmascript object (not host objects)
But anything else outside core ecmascript is free to release the mutex
if it wants. Eg any call to dom or any access to any object provided
by the host. Rather than telling them what *can* release the mutex, we
instead tell them to assume that everything can unless it is in our
list of things that *can't*.
This is intentionally broad for several reasons:
* to avoid us having to work out the full list of all cases that could
require any user agent to release the mutex
* to give users an easy rule that they can remember and know will
always be safe on any user agent
* to give the user agent the freedom to release the mutex as soon as
possible, thus improving concurrency [I am rep for Intel so I care
about this]
Apologies for being vague earlier.
-Rob
On Nov 5, 2009, at 10:16 AM, Jeremy Orlow <jor...@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.enn...@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.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