On Mon, Mar 23, 2009 at 8:07 AM, Michael Nordman <span dir="ltr"><<a href="mailto:michaeln@google.com">michaeln@google.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
I don't see how denying workers solves the problem. In a multi-threaded browser, this has to be resolved reasonably even in the absence of workers. <div class="gmail_quote">
<div></div></div></blockquote><div> </div></div>It has to be resolved in a way that doesn't expose asynchronous cookie or localStorage changes to Web developers. There is abundant evidence that race conditions and synchronization are too hard for developers to deal with. The spec should forbid asynchronously visible changes to cookies or localStorage. In fact, it should probably simply say that all script execution is serializable: always equivalent to some execution you could get with a single-threaded browser that runs all scripts to completion. Allowance could be made for explicit yield points if we need to, e.g. alert().<br>
<br>If IE7+ allows asynchronous cookie changes, that is a bad bug. Perhaps today they get away with it because people aren't writing long-running scripts that use cookies as read/write storage. We shouldn't take that as a sign that the shared-state threaded programming model somehow works better on the Web than it does everywhere else.<br>
<br>Some sort of implicit locking with guaranteed deadlock freedom should be workable for parallel browser implementations. For example, partition browser contexts into "related" subsets, where context A is related to context B if a script running in context A can affect the execution of an already-running script in context B. Use one lock per subset, and have a script execution acquire the lock when it first touches localStorage or cookies, and drop the lock when it completes (or yields). Additional optimizations are possible.<br>
<br>An asynchronous API like the multi-resource-acquisition callback Jonas just proposed, would be helpful to enable additional parallelism. By declaring up-front which resources need to be locked and guaranteeing that only those resources will be touched, you can use a finer-grained locking scheme without risking deadlock.<br>
<br clear="all">Rob<br>-- <br>"He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all." [Isaiah 53:5-6]<br>