Re: [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.mozi...@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

Re: [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

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

On Thu, Apr 1, 2010 at 4:40 PM, Drew Wilson atwil...@google.com wrote: 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

Re: [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,

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

On Thu, 1 Apr 2010, Dmitry Titov wrote: 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: [...] I'm fine with doing this. Not sure about onclose

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

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

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

I see, thanks for the details! This makes sense - you let the worker run unrestricted (ports still send messages, sync API work) until it exits JS code. It is one of two possibilities I though of as well (run unrestricted while in JS or immediate termination). BTW, the current Worker spec and

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

Hi! Trying to fix some bugs for Workers, I've got some questions about close() method on WorkerGlobalScopehttp://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

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

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

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

On Tue, Mar 30, 2010 at 5:58 PM, Drew Wilson atwil...@google.com wrote: 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#127b1baa1cefaebf_kill-a-worker processing model on a worker at