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

Thanks Jonas!

So there is somewhat of a consensus on close() to effectively let a worker
run normally until the exit from the current JS fragment. It makes sense for
us as well.

I think the only change to the spec here would be the removal of the 3rd
line in the description of what close() does, so the ports are still
functional, at least for posting from the worker:

When a script invokes the close() method on a WorkerGlobalScope object, the
> user agent must run the following steps (atomically):


> Discard any tasks that have been added to the event loop's task queues.

Set the worker's WorkerGlobalScope object's closing flag to true. (This
> prevents any further tasks from being queued.)

Disentangle all the ports in the list of the worker's ports.


.. which probably is not a big deal (hope Ian will chime in on this).

Not sure about onclose indeed...  Perhaps we can use some time to see if
developers will request something like this more explicitly, then we could
think about it more.

Dmitry

On Thu, Apr 1, 2010 at 3:31 PM, Jonas Sicking <jonas at sicking.cc> wrote:

> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100401/f1e41d1f/attachment-0001.htm>

Received on Thursday, 1 April 2010 16:57:06 UTC