On Wed, Feb 24, 2010 at 9:07 PM, David Flanagan <span dir="ltr"><<a href="mailto:david@davidflanagan.com">david@davidflanagan.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<div class="im">Jeremy Orlow wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Also note that the spec currently has the notion of a storage mutex which should be taken whenever a script tries to access a cookie (or local storage) and is held until the script finishes.  The network stack is also supposed to take this lock whenever getting or setting a cookie.  No one has implemented the storage mutex or stated any intention of doing so because this is basically impossible today.  But, if there were an asynchronous API that most people were using, it actually could be possible that we'd want to implement such a mutex since cookies would then obey run to completion semantics without having serious lock contention.<br>


<br>
</blockquote>
<br></div>
Well if no one is going to implement the storage mutex, then I probably need to retract my last message<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
But yeah.  Definitely any API that touches information spanning tabs (and probably even APIs spanning origins within those tabs) really should be designed in an async manor from now on.  Otherwise we're just digging the whole deeper in terms of forcing ourselves into a single threaded world.<br>


<br>
J<br>
</blockquote>
<br></div>
I worry that this comes down to web developers who want simple APIs vs browser implementors who say we can't have them (at least not if we also want speed.)<br>
<br>
Concurrency issues are not my strong suit, but shouldn't it be possible to have safe, synchronous read-only access to cookies (caching volatile values like cookies within each thread and then clearing that cache when the thread returns to the event loop).  Can't the requirement for a mutex or an asynchronous API be limited to setCookie()?<br>

</blockquote><div><br></div><div>From a technical standpoint, this is very doable.  And, done right, I think I could be in favor of it.</div><div><br></div><div>But I believe the counter argument is that any relaxation of run to completion semantics is going to confuse developers and probably result in them writing racy code without realizing it.  Many developers won't understand when it's safe to use the cached value vs needing to use the asynchronous interface.  And if the less safe one is easier to use....</div>

<div><br></div><div>I agree that asynchronous interfaces have disadvantages, but as far as I can tell many of them are costs that you pay once (learning them and getting use to them) or once per app (if you handle one asynchronous call or need to use setTimeout, then probably using another won't require too much restructuring of your code).  Maybe I'm just a browser developer who's completely out of touch with reality though.  :-)</div>

</div>