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

How does the GC-initiated close() event work in Firefox, in the case of a
fire-and-forget worker?

For example:

foo.html:
<script>
new Worker("forget.js");
</script>

forget.js:
self.setInterval(function() { ...do something...}, 1000);

In this case, it seems incorrect to ever fire a close() event until the
parent window leaves the bfcache. I'm guessing you must do something to
prevent the worker object from being GC'd in the case that there's pending
activity in the worker?

-atw

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/73b37532/attachment.htm>

Received on Thursday, 1 April 2010 16:40:47 UTC