So I get what you are saying - from an implementation standpoint, any access to shared data exposes the asynchronously threaded nature of workers to the developer, without giving them any tools to manage this access (locks, etc).<br>
<br>For cookies, I'd always assumed that cookie state was mutable, since the server could set the cookie state via an HTTP response coming down in parallel with the execution of javascript. Perhaps the spec makes guarantees about the immutability of document.cookies? It doesn't seem to:<br>
<br>"Otherwise, the user agent must act as
  it would when processing cookies if it had just attempted to
  <a href="http://www.whatwg.org/specs/web-apps/current-work/#fetch">fetch</a> <a href="http://www.whatwg.org/specs/web-apps/current-work/#the-document%27s-address">the document's address</a> over HTTP,
  and had received a response with a <code>Set-Cookie</code> header
  whose value was the specified value, as per RFC 2109 sections 4.3.1,
  4.3.2, and 4.3.3 or later specifications, but without overwriting
  the values of HTTP-only cookies. <a href="http://www.whatwg.org/specs/web-apps/current-work/#refsRFC2109">[RFC2109]</a> <a href="http://www.whatwg.org/specs/web-apps/current-work/#refsRFC2965">[RFC2965]</a>"<br><br>
It seems like developers shouldn't be depending on the value of document.cookie being static anyway.<br><br>-atw<br><br><div class="gmail_quote">On Thu, Mar 5, 2009 at 5:55 PM, Jonas Sicking <span dir="ltr"><jonas@sicking.cc></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="im">On Thu, Mar 5, 2009 at 5:44 PM, Drew Wilson <<a href="mailto:atwilson@google.com">atwilson@google.com</a>> wrote:<br>

> So an asynchronous cookie setting API would look like:<br>
><br>
> setCookie(cookieStr, callback)<br>
><br>
> ...where the callback is invoked once the cookie has been set?<br>
><br>
> I guess I don't yet entirely understand the implementation details - it<br>
> sounds like there are problems accessing any shared state between workers<br>
> and window context?<br>
<br>
</div>The problem is with code like the following:<br>
<br>
if (sharedState < 0) {<br>
  sharedState = sharedState * -1;<br>
}<br>
<br>
You would expect sharedState to always be non-negative at the end of<br>
such a program, right? Well, that might not be the case since script<br>
running in parallel in the main window might have changed the value of<br>
sharedState from -5 to 10 between the if-statement and the assignment,<br>
resulting in sharedState being -10 at the end.<br>
<br>
This is why workers use a shared-nothing message passing interface<br>
between workers and windows. This is something that simply can't be<br>
fixed in the implementation, but something that scripts would have to<br>
deal with themselves. It's unlikely that web developers would do this<br>
correctly since working with threads is *very hard* and something that<br>
even seasoned developers often get wrong.<br>
<font color="#888888"><br>
/ Jonas<br>
</font></blockquote></div><br>