[whatwg] Combining the DedicatedWorker and SharedWorker interfaces

Ian Hickson wrote:
> On Thu, 13 Nov 2008, Jonas Sicking wrote:
>> Honestly I'm not really sure why the spec says that you need a list at 
>> all, other than maybe to talk about GC (which i've many times mentioned 
>> I think the spec should not need to "define").
> 
> I remembered what it was that I was trying to remember the last time we 
> spoke about this -- the case that the spec is trying to define that I 
> don't know how to define in any other way is the case where a worker has 
> no non-GC'ed communication mechanisms with the outside world (e.g. the 
> Worker object is dropped and GC'ed on the outside, there are no message 
> handlers set up, and there are no other ports around), but the worker has 
> a timer set up [1] to do some work that can have side-effects. Without 
> defining when GC happens, there would be a detectable way to tell that the 
> worker went away. We want such workers to keep going until the document 
> that they were associated with is navigated away.
> 
> That's what the text in the spec is doing. (It also defines when a worker 
> should be suspended, for similar reasons.)
> 
> I don't really see how we can do away with this without interop issues.

It sounds to me like simply saying:

setTimout(handler, ms):
   When called will schedule a event 'ms' milliseconds after the function
   is called. When the event fires 'handler' is called.

would make it a bug to not fire the event and produce any side effects 
that it would have. For exactly the same reasons that canceling a 
pending XHR request would be a bug.

(The above is obviously a far simplification of setTimeout)

/ Jonas

Received on Thursday, 13 November 2008 23:11:29 UTC