<br><div class="gmail_quote">On Tue, Mar 30, 2010 at 5:58 PM, Drew Wilson <span dir="ltr"><<a href="mailto:atwilson@google.com">atwilson@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
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 style="font-family:sans-serif, 'Droid Sans Fallback';font-size:medium;line-height:21px">User agents may invoke the "<a href="#127b1baa1cefaebf_kill-a-worker" style="color:rgb(0, 0, 204);background-color:transparent;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="#127b1baa1cefaebf_active-needed-worker" style="color:rgb(0, 0, 204);background-color:transparent;background-repeat:initial initial">active needed worker</a> if the worker continues executing even after its <a href="#127b1baa1cefaebf_dom-workerglobalscope-closing" title="dom-WorkerGlobalScope-closing" style="color:rgb(0, 0, 204);background-color:transparent;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>
</blockquote><div><br></div><div>Yes, and this, after many hours of troubles, may eventually crystallize into "don't have any code after close() in your worker code" rule-of-thumb for web developers. Which is basically a bad thing...</div>
<div>This is why it could be better to specify explicitly that either execution is immediately terminated or it runs until JS exits with full functionality of the worker, not in a special almost-closed mode. Having a timeout </div>
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<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>
</blockquote><div><br></div><div>This applies as long as the browser still executes the code after close(). In WebKit V8 case, we terminate execution almost instantly, so we don't even run the code that causes an error :-) If we are not to terminate execution instantly, then it'd be nice to say the script runs until it ends (or parent document closes, which actually terminates the script forcefully), and not have a requirement to stop the queue or disconnect ports, as to not create a whole new 'mode of worker execution' which needs to have a spec on its own since all other features will need to be mentions (like sync APIs).</div>
<div><br></div><div>It's not clear why a fixed timeout would be useful. It would create some randomness in what a worker can still do after calling close(). I think web developers would then rather do those things before calling close(), to avoid random results.</div>
<div><br></div><div>But if we say close() lets script run until completion (but prevents further messages/events from dispatching), then perhaps we don't need it at all - there is nothing then that script in the worker can not do to the same effect (unregister onmessage, clear timers etc). </div>
<div><br></div><div>That means letting worker to call close() on itself only makes additional sense if it is specified as immediate termination. It could be useful and it can be specified in deterministic manner.</div><div>
<br></div><div>On a separate note, I agree with giving workers some time before terminating them in case the parent page closes - but this is the case when forces outside and async to the worker need to close it. I think it's different when worker's own script wants to terminate - it could do its last wishes before calling close() as well.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div><br></div><div>-atw</div><div><div></div><div class="h5"><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" target="_blank">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>
</div></div></blockquote></div><br>