[whatwg] Combining the DedicatedWorker and SharedWorker interfaces
Jonas Sicking
jonas at sicking.cc
Thu Nov 13 23:11:29 PST 2008
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
More information about the whatwg
mailing list