[whatwg] Workers: What can be done in a worker after call to close()?

[Drew Wilson]

I'll note that the spec gives the UA an significant amount of latitude about
its behavior after close() is called:

User agents may invoke the "kill a worker <#kill-a-worker>" 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 active needed
worker<#active-needed-worker> if
the worker continues executing even after its
closing<#dom-workerglobalscope-closing> flag
was set to true.

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.

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.

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.

-atw



On Tue, Mar 30, 2010 at 4:44 PM, Dmitry Titov <dimich at chromium.org> wrote:

> Hi!
>
> Trying to fix some bugs for Workers, I've got some questions about close()
> method on WorkerGlobalScope<http://www.whatwg.org/specs/web-workers/current-work/#workerglobalscope>
> .
>
> 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.
>
> This seems to leave some questions without explicit answer, with
> differences in current implementations:
>
> 1. Does this code in a worker continues looping until the parent page
> unloads:
>  ...
>  close();
>  while(true) {}
>
> WebKit V8 terminates, WebKit JCS terminates after a timeout, FF does not
> terminate.
>
> 2. Do the errors propagate back to Worker object after close()?
> ...
> close();
> nonExistingFunction();  <<-- throws, if not processed locally, posts error
> info to the Worker object.
>
> In WebKit and FF errors propagate, although it does not seem consistent
> while worker closed all the ports and is in a dormant state.
>
> 3. Should synchronous operations work after close()? Asynchronous ones
> perhaps should not, because of the event loop queue which is stopped...
> ...
> close();
> xhr.open("GET", "foo.com", *false*);
> xhr.send();
>
> WebKit: does not work (mostly), FF - does work.
>
> 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.
>
> Any opinions?
>
> Thanks,
> Dmitry
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100330/e03c53d2/attachment.htm>