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

On Wed, Mar 31, 2010 at 10:03 AM, ben turner <bent.mozilla at gmail.com> wrote:
> Hi,
>
> When implementing the close() function for Firefox we chose to set the
> closing flag and clear pending events only. As the worker script is
> calling close() on itself we figured that the worker should retain
> maximum functionality until it has finished execution (otherwise it
> could just not call close() and rely on some kind of postMessage() and
> terminate() combo). Therefore we do not enforce any timeout for the
> currently executing script and we continue to allow postMessage()
> calls and synchronous XHR to proceed. Since the closing flag is set in
> response to close() the worker is guaranteed to finish as soon as the
> currently running script finishes. We always enforce a timeout for any
> code that runs in response to the close event that gets fired after
> the current script finishes, though.
>
> If the code that calls close() never returns (like the while(1) { }
> example above) then the worker will never finish, as pointed out
> above, but that's no different than having a worker script that
> consists only of a while(1) { } loop and we don't think it's important
> to prevent. If a worker script is written in this way then a
> terminate() call is still a valid solution.
>
> Also, since we try to retain maximum functionality after close() we
> also allow errors to propagate as shown above.
>
> If anyone is curious the basic strategy we use in response to close
> functions (like close(), terminate(), and for UA-generated events like
> when the main worker object is GC'd) can be found in the following
> table:
>
> http://mxr.mozilla.org/mozilla-central/source/dom/src/threads/nsDOMWorker.h#202

For what it's worth, I think the behavior that firefox has makes a lot
of sense and I think it should be mandated by the spec. (I know, big
shocker :) )

The one thing that we do and that is somewhat iffy is the close event.
Ben actually gets it a bit wrong in the description above. This is how
it works:

We fire the close event handler in four situations:

* After close() is called by the worker, once it finishes its current execution.
* After terminate() is called from outside the worker and any code
running has been aborted.
* If the worker is garbage collected.
* Once the user leaves the page (or specifically, once the page falls
out of the bfcache).

Only in the last case do we give the close handler a time limit, after
which any currently running close handler is aborted and no more close
handlers are run.

Though of course the user can leave the page *while* the close event
is getting fired. If so, we start the time limit at that point.

The iffy part is the third bullet above, since it exposes GC behavior.
This is very unfortunate indeed and because of it I feel that our
implementation is somewhat experimental.

We could simply not fire the close event in that case, however this
would seem to reduce the usefulness of the close event quite a bit.

So I think for now I don't care if the close event is put in the spec
or not. But I wanted to let you know what we're doing. We don't
currently have any plans to remove it.

/ Jonas

Received on Thursday, 1 April 2010 15:31:03 UTC