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.<div>
<br></div><div>Does anyone have any ideas on what the exact language for what an "API operation" might look like?</div><div><br></div><div><br></div><div>I do have a couple of concerns though:</div><div>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).</div>
<div><br></div><div>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.</div>
<div><br></div><div>I'm interested to hear what others have to say on this proposal.</div><div><br></div><div>J</div><div><br></div><div><br><div class="gmail_quote">On Wed, Nov 4, 2009 at 3:31 PM, Rob Ennals <span dir="ltr"><<a href="mailto:rob.ennals@gmail.com">rob.ennals@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Missed out the important final qualifier. Here's take 3:<br>
<br>
"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/"<br>
<br>
If a local storage op can release the mutex then the whole thing is pointless :-)<br><font color="#888888">
<br>
-Rob</font><div><div></div><div class="h5"><br>
<br>
On Nov 4, 2009, at 3:15 PM, Rob Ennals <<a href="mailto:rob.ennals@gmail.com" target="_blank">rob.ennals@gmail.com</a>> wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I suspect my suggested spec line was insufficiently precise. How about this:<br>
<br>
"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"<br>
<br>
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.<br>
<br>
-Rob<br>
<br>
On Nov 4, 2009, at 2:56 PM, Mike Shaver <<a href="mailto:mike.shaver@gmail.com" target="_blank">mike.shaver@gmail.com</a>> wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Wed, Nov 4, 2009 at 5:51 PM, Rob Ennals <<a href="mailto:rob.ennals@gmail.com" target="_blank">rob.ennals@gmail.com</a>> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Or to put it another way: if the thread can't call an API then it can't<br>
block waiting for another storage mutex, thus deadlock can't occur, thus we<br>
don't need to release the storage mutex.<br>
</blockquote>
<br>
Right, but the spec text there doesn't prevent the UA from releasing<br>
more than in that scenario, which seems like it's not an improvement<br>
over where we are right now: unpredictable consistency. Existing racy<br>
implementations like in IE would be conformant, so developers can't<br>
count on the script-sequenced-storage-ops pattern providing<br>
transactionality.<br>
<br>
More likely, though, _I_'m missing something...<br>
<br>
Mike<br>
</blockquote>
<br>
</blockquote>
</div></div></blockquote></div><br></div>