- From: Jonas Sicking <jonas@sicking.cc>
- Date: Thu, 28 Aug 2008 09:59:27 -0700
Some comments: The spec currently says: Once the WorkerGlobalScope's closing flag is set to true, the queue must discard anything else that would be added to it. Effectively, once the closing flag is true, timers stop firing, notifications for all pending asynchronous operations are dropped, etc. Does this mean that anything already on the queue will remain there? Or will it be dropped? It sounds like it will remain, but it's somewhat unclear. In general I think the three shutdown mechanisms that exist are somewhat messy: * Kill a worker * Terminate a worker * WorkerGlobalScope.close() It seems excessive with 3 possible shutdown sequences, but more importantly the differences between them seems unnecessarily big. Mostly for users, but to a small extent also for implementors. Currently the situation is as follows: | Abort | Processes | Fires | Fires | current | more | close on | close on | script | events | scope | tangled | | | | ports --------------------------------------------------------------------- Kill a worker | Maybe[1]| Maybe[1] | Maybe[1] | No Terminate a worker | Yes | No | Yes | No WorkerGlobalScope.close() | No | Maybe[2] | Yes | Yes --------------------------------------------------------------------- [1] Implementation dependent. Presumably depends on how much patience that the implementation thinks its users has. [2] Depends on if the even has been placed in the queue yet or not, somewhat racy. This seems excessively messy. The number of differences in the columns and the number of maybes seems bad. I propose the following: * Remove the "Kill a worker" algorithm and use "Terminate a worker" everywhere it is used. * Make WorkerGlobalScope not process any more events. I.e. make setting the 'closing flag' to true always clear out all events except a single close event. * Always fire close on tangled ports. In many cases this will be a no-op since we're doing it in workers that are being closed. However if the port is in another window or a shared worker this might not be the case. Basically an implementation is already allowed to do the first bullet given the amount of implementation-specificness of "Kill a worker". The second bullet seem like a good idea just to reduce the amount of racyness when a worker is closing itself. The third bullet I suspect is simply a bug in the current spec? / Jonas
Received on Thursday, 28 August 2008 09:59:27 UTC