Hi all,<div><br></div><div>There have been various side discussions regarding the stability/viability of Workers and SharedWorkers, and I wanted to make sure we understand all of the concerns, since as far as I know there isn&#39;t any one person who has been privy to all of the conversations (or maybe it&#39;s just me that&#39;s been out of the loop :). So I&#39;ll enumerate the issues I&#39;m aware of below, and people can chime in on any that I&#39;ve missed that may impact the ability to ship these features, and we can figure out how to get them addressed ASAP.</div>

<div><br></div><div>1) worker-lifecycle.html fails intermittently (<a href="https://bugs.webkit.org/show_bug.cgi?id=29344" target="_blank">https://bugs.webkit.org/show_bug.cgi?id=29344</a>)</div><div><br></div><div>The original report doesn&#39;t seem to be a true worker failure, but rather an artifact of the way GC works in JSC. Since JSC uses conservative GC, it&#39;s quite possible for the VM to think that there&#39;s a dangling reference to a Worker even though there isn&#39;t actually one, and that seems to be what&#39;s happening here (workers would get shutdown when the parent document closes regardless, so there&#39;s no actual leak). Unless someone has some idea of how to make this GC more deterministic, my recommendation would be to just disable this test and close this bug, since seemingly it&#39;s the test itself that is not reliable, not the underlying worker code.</div>
<div><br></div><div>That said, there&#39;s a sporadic worker crash that seems to have started happening in the last week or so which I believe is a different issue - eseidel has glommed that crash onto the same bug, and I think we should move that to its own issue and see if we can collect more information about it.</div>

<div><br></div><div>2) SharedWorkers proxy their network access to a parent document (no bug for this currently)</div><div><br></div><div>The result of this is the application can get a network error if the user has multiple windows open that are using the same SharedWorker, then closes the parent document that is acting as a network proxy while a network request is in progress. While this is something that would need to change eventually in order to properly support exposing the appcache APIs to SharedWorker context, it doesn&#39;t seem like this would be any kind of ship blocker. Any robust application would need to deal with sporadic network hiccups anyway by retrying, and in practice this situation will almost never be encountered in the field. Perhaps people have other concerns that make this a ship blocker?</div>

<div><br></div><div>3) Potential race conditions with Document.postTask() (<a href="https://bugs.webkit.org/show_bug.cgi?id=31633">https://bugs.webkit.org/show_bug.cgi?id=31633</a>)</div><div><br></div><div>I&#39;ve suggested a simple solution to the potential race condition with SharedWorkers in the bug. I&#39;d be interested in hearing whether people think it&#39;s a good approach or not - if so, I&#39;m happy to submit a patch for review in short order. There&#39;s still the question as to whether dispatching tasks on a detached Document is OK or not, but I&#39;m assuming it is (since that&#39;s what Dedicated workers have always done).</div>
<div><br></div><div>Are there other issues we should be addressing as a high priority?</div><div><br></div><div>-atw</div>