[whatwg] Workers

[Jonas Sicking]

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