- From: Jonas Sicking <jonas@sicking.cc>
- Date: Thu, 13 Nov 2008 23:11:29 -0800
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