That version is fine with me.
My reason for using MAY was I thought it would make efficient
implementation easier. Also, testing when things are being unlocked is
pretty much impossible for users due to the statistical nature of race
conditions and shedulers.
But yeah, SHALL is better semantically, if everyone is happy to
imlement that.
-Rob
On Nov 5, 2009, at 11:06 AM, Scott Hess <[email protected]> wrote:
"user agent MAY release" means that people will write code which works
now, and later the browser vendor will make a change that will break
their code. Who is at fault? We all know that the browser vendor is
at fault!
Suggest "the user agent SHALL release the storage mutex on any API
operation /other that a local storage operation/". The user agent is
free to do internal optimizations to make things super efficient if
there's only one local storage op client. But this means that the web
developer's practical experience will lead them to the right place.
-scott
On Thu, Nov 5, 2009 at 11:16 AM, Jeremy Orlow <[email protected]>
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 <[email protected]>
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 <[email protected]> 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 <[email protected]>
wrote:
On Wed, Nov 4, 2009 at 5:51 PM, Rob Ennals
<[email protected]> 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
