I'll note that the spec gives the UA an significant amount of latitude about its behavior after close() is called:<div><br></div><div><span class="Apple-style-span" style="font-family: sans-serif, 'Droid Sans Fallback'; font-size: medium; line-height: 21px; ">User agents may invoke the "<a href="#kill-a-worker" style="color: rgb(0, 0, 204); background-image: initial; background-attachment: initial; background-origin: initial; background-clip: initial; background-color: transparent; background-position: initial initial; background-repeat: initial initial; ">kill a worker</a>" processing model on a worker at any time, e.g. in response to user requests, in response to CPU quota management, or when a worker stops being an <a href="#active-needed-worker" style="color: rgb(0, 0, 204); background-image: initial; background-attachment: initial; background-origin: initial; background-clip: initial; background-color: transparent; background-position: initial initial; background-repeat: initial initial; ">active needed worker</a> if the worker continues executing even after its <a href="#dom-workerglobalscope-closing" title="dom-WorkerGlobalScope-closing" style="color: rgb(0, 0, 204); background-image: initial; background-attachment: initial; background-origin: initial; background-clip: initial; background-color: transparent; background-position: initial initial; background-repeat: initial initial; ">closing</a> flag was set to true.</span></div>
<div><br></div><div>Essentially, UAs can kill a worker at any time, and since the "kill a worker" algorithm allows UAs to abort the script after a user-agent-defined amount of time (including zero), it seems like almost any behavior post-close is compliant. This seems like a guaranteed source of cross-browser incompatibilities.</div>
<div><br></div><div>I've always operated under the impression that the intent of the spec is to allow pending worker operations to complete, but still give UAs the ability to abort scripts that don't exit in a timely manner (so close() should not immediately abort the script), but I don't see anything in the spec regarding this.</div>
<div><br></div><div>For #2 below, I believe that exceptions in worker context should *always* be reported, regardless of closing state. Section 4.6 (Runtime script errors) makes no mention of tying this behavior to the closing flag.</div>
<div><br></div><div>-atw</div><div><br></div><div><br><br><div class="gmail_quote">On Tue, Mar 30, 2010 at 4:44 PM, Dmitry Titov <span dir="ltr"><<a href="mailto:dimich@chromium.org">dimich@chromium.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div>Hi!</div><div><br></div><div>Trying to fix some bugs for Workers, I've got some questions about <a href="http://www.whatwg.org/specs/web-workers/current-work/#workerglobalscope" target="_blank">close() method on WorkerGlobalScope</a>.</div>
<div><br></div><div>In particular, the spec seems to imply that after calling close() inside the worker, the JS does not get terminated right away, but rather continue to execute, while an internal 'closing' flag is set and a message queue associated with the worker discards all the tasks, existing and future. Also, all ports are immediately disentangled.</div>
<div><br></div><div>This seems to leave some questions without explicit answer, with differences in current implementations:</div><div><br></div><div>1. Does this code in a worker continues looping until the parent page unloads:</div>
<div> ...</div><div> close();</div><div> while(true) {}</div><div><br></div><div>WebKit V8 terminates, WebKit JCS terminates after a timeout, FF does not terminate.</div><div><br></div><div>2. Do the errors propagate back to Worker object after close()?</div>
<div>...</div><div>close();</div><div>nonExistingFunction(); <<-- throws, if not processed locally, posts error info to the Worker object.</div><div><br></div><div>In WebKit and FF errors propagate, although it does not seem consistent while worker closed all the ports and is in a dormant state.</div>
<div><br></div><div>3. Should synchronous operations work after close()? Asynchronous ones perhaps should not, because of the event loop queue which is stopped...</div><div>...</div><div>close();</div><div>xhr.open("GET", "<a href="http://foo.com" target="_blank">foo.com</a>", <b>false</b>);</div>
<div>xhr.send();</div><div><br></div><div>WebKit: does not work (mostly), FF - does work.</div><div><br></div><div>Perhaps it would be simpler to either say nothing is executed/posted/fired after close() (immediate termination), or to enable worker run unimpeded (with ports open, etc) until it naturally yields from JS.</div>
<div><br></div><div>Any opinions?</div><div><br></div><div>Thanks,<br>Dmitry</div><div><br></div><div><br></div>
</blockquote></div><br></div>