[webkit-dev] Proposed Timer API

Maciej Stachowiak mjs at apple.com
Fri Oct 3 14:54:34 PDT 2008


On Oct 3, 2008, at 2:47 PM, Chris Marrin wrote:

>
>
> I think the reason you don't see the pattern of deferred timer  
> triggering is because today you just can't do it. I think the use  
> case I described (triggering a timer on an animation or media event)  
> will be common if and when we have that ability.

You can do it by passing around the relevant timer parameters  
separately (in an array or ad-hoc dictionary object) - this does not  
appear to be done very often.

>
> In the above example, does the system guarantee that starting a  
> timer and immediately stopping it will not ever fire that timer?

Yes.

> I can't imagine that guarantee being possible, especially for very  
> short (or zero) duration timers. If an implementation chooses to  
> queue up timer events as soon as they time out (plus the  
> optimization that zero duration timers would immediately queue),  
> they would have to dig into that queue and rip out any timers that  
> are stopped.

I don't know about a hypothetical implementation, but in WebKit's  
implementation of timers it would work fine and would not be at all  
difficult. We have a priority queue and skip stopped timers when  
pulling ones that have passed their fire date out of the queue. You  
have to do that correctly anyway, even for the old school setTimeout/ 
cancelTimeout APIs.

> And that might not even be desirable in many cases. What should  
> happen when a timer times out while a JS function is running and you  
> stop it? Should its event still run.

No it should not.

> I'm sure there are many interesting race conditions possible here.

There aren't multiple threads involved, so no possibility of race  
conditions.

> It seems like you would avoid these issues if you could have a param  
> to startTimer (or a separate createTimer function) that prevented  
> the timer from starting in the first place.

I think a createTimer function would not ease implementation in any  
way. Its only purpose would be a minor convenience to authors who want  
to create a timer that is not initially running. It is not clear to me  
if this is a common enough use case.

Regards,
Maciej



More information about the webkit-dev mailing list