2012-02-27 20:09:34 +01:00
|
|
|
# Timers
|
2010-10-28 14:18:16 +02:00
|
|
|
|
2012-03-03 00:14:03 +01:00
|
|
|
Stability: 5 - Locked
|
|
|
|
|
2012-02-27 20:09:34 +01:00
|
|
|
All of the timer functions are globals. You do not need to `require()`
|
|
|
|
this module in order to use them.
|
|
|
|
|
|
|
|
## setTimeout(callback, delay, [arg], [...])
|
2010-10-28 14:18:16 +02:00
|
|
|
|
2011-08-31 15:12:34 +02:00
|
|
|
To schedule execution of a one-time `callback` after `delay` milliseconds. Returns a
|
|
|
|
`timeoutId` for possible use with `clearTimeout()`. Optionally you can
|
2010-10-28 14:18:16 +02:00
|
|
|
also pass arguments to the callback.
|
|
|
|
|
2011-09-14 05:02:54 +02:00
|
|
|
It is important to note that your callback will probably not be called in exactly
|
|
|
|
`delay` milliseconds - Node.js makes no guarantees about the exact timing of when
|
|
|
|
the callback will fire, nor of the ordering things will fire in. The callback will
|
|
|
|
be called as close as possible to the time specified.
|
|
|
|
|
2012-02-27 20:09:34 +01:00
|
|
|
## clearTimeout(timeoutId)
|
2010-10-28 14:18:16 +02:00
|
|
|
|
|
|
|
Prevents a timeout from triggering.
|
|
|
|
|
2012-02-27 20:09:34 +01:00
|
|
|
## setInterval(callback, delay, [arg], [...])
|
2010-10-28 14:18:16 +02:00
|
|
|
|
|
|
|
To schedule the repeated execution of `callback` every `delay` milliseconds.
|
2011-08-31 15:12:34 +02:00
|
|
|
Returns a `intervalId` for possible use with `clearInterval()`. Optionally
|
2010-10-28 14:18:16 +02:00
|
|
|
you can also pass arguments to the callback.
|
|
|
|
|
2012-02-27 20:09:34 +01:00
|
|
|
## clearInterval(intervalId)
|
2010-10-28 14:18:16 +02:00
|
|
|
|
|
|
|
Stops a interval from triggering.
|
2012-07-13 21:08:32 +02:00
|
|
|
|
|
|
|
## unref()
|
|
|
|
|
|
|
|
The opaque value returned by `setTimeout` and `setInterval` also has the method
|
|
|
|
`timer.unref()` which will allow you to create a timer that is active but if
|
|
|
|
it is the only item left in the event loop won't keep the program running.
|
|
|
|
If the timer is already `unref`d calling `unref` again will have no effect.
|
|
|
|
|
|
|
|
In the case of `setTimeout` when you `unref` you create a separate timer that
|
|
|
|
will wakeup the event loop, creating too many of these may adversely effect
|
|
|
|
event loop performance -- use wisely.
|
|
|
|
|
|
|
|
## ref()
|
|
|
|
|
|
|
|
If you had previously `unref()`d a timer you can call `ref()` to explicitly
|
|
|
|
request the timer hold the program open. If the timer is already `ref`d calling
|
|
|
|
`ref` again will have no effect.
|
2012-08-08 04:12:01 +02:00
|
|
|
|
|
|
|
## setImmediate(callback, [arg], [...])
|
|
|
|
|
2013-02-06 03:14:24 +01:00
|
|
|
To schedule the "immediate" execution of `callback` after I/O events
|
|
|
|
callbacks and before `setTimeout` and `setInterval` . Returns an
|
|
|
|
`immediateId` for possible use with `clearImmediate()`. Optionally you
|
|
|
|
can also pass arguments to the callback.
|
2012-08-08 04:12:01 +02:00
|
|
|
|
|
|
|
Immediates are queued in the order created, and are popped off the queue once
|
|
|
|
per loop iteration. This is different from `process.nextTick` which will
|
|
|
|
execute `process.maxTickDepth` queued callbacks per iteration. `setImmediate`
|
|
|
|
will yield to the event loop after firing a queued callback to make sure I/O is
|
|
|
|
not being starved. While order is preserved for execution, other I/O events may
|
|
|
|
fire between any two scheduled immediate callbacks.
|
|
|
|
|
|
|
|
## clearImmediate(immediateId)
|
|
|
|
|
|
|
|
Stops an immediate from triggering.
|