W3C home > Mailing lists > Public > whatwg@whatwg.org > August 2008

[whatwg] Workers

From: Jonas Sicking <jonas@sicking.cc>
Date: Thu, 28 Aug 2008 11:33:52 -0700
Message-ID: <48B6EF90.3010106@sicking.cc>
Jonas Sicking wrote:
> 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.

Sorry, the second bullet should say:

* Make WorkerGlobalScope.close() not process any more events. I.e. make 
setting the 'closing flag' to true always clear out all events except a 
single close event.

/ Jonas
Received on Thursday, 28 August 2008 11:33:52 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:05 UTC