Timers have a relatively high priority in the event queue. Thus, if the timer delay is set low enough, repeated notification for a timer can preempt user activities (which might be directed at stopping the timer). For timers with relatively short delays, call yield within the notify procedure to allow guaranteed event processing.
See Event Dispatching and Eventspaces for more information about event priorities.
| ||||||||||||
→ (is-a?/c timer%) | ||||||||||||
notify-callback : (-> any) = void | ||||||||||||
interval : (or/c (integer-in 0 1000000000) false/c) = #f | ||||||||||||
just-once? : any/c = #f |
If interval is #f (the default), the timer is not started; in that case, start must be called explicitly. If interval is a number (in milliseconds), then start is called with interval and just-once?.
(send a-timer interval) → (integer-in 0 1000000000) |
Default implementation: Calls the notify-callback procedure that was provided when the object was created.
(send a-timer start msec [just-once?]) → void? |
msec : (integer-in 0 1000000000) |
just-once? : any/c = #f |
The timer’s alarm expires after msec milliseconds, at which point notify is called (on an event boundary). If just-once? is #f, the timer expires every msec milliseconds until the timer is explicitly stopped. (More precisely, the timer expires msec milliseconds after notify returns each time.) Otherwise, the timer expires only once.