vibe.d beta banner
get vibe.d
0.10.1

Asynchronous I/O that doesn’t get in your way, written in D

setTimer - multiple declarations

Function setTimer

Creates a new timer, that will fire callback after timeout

Timer setTimer (
  core.time.Duration timeout,
  nothrow @safe void delegate() callback,
  bool periodic = false
) nothrow @safe;

Timers can be be separated into two categories: one-off or periodic. One-off timers fire only once, after a specific amount of time, while periodic timer fire at a regular interval.

One-off_timers: One-off timers can be used for performing a task after a specific delay, or to schedule a time without interrupting the currently running code. For example, the following is a way to emulate a 'schedule' primitive, a way to schedule a task without starting it immediately (unlike runTask):

void handleRequest (scope HTTPServerRequest req, scope HTTPServerResponse res) {
	Payload payload = parse(req);
	if (payload.isValid())
	  // Don't immediately yield, finish processing the data and the query
	  setTimer(0.msecs, () => sendToPeers(payload));
	process(payload);
	res.writeVoidBody();
}

In this example, the server delays the network communication that will be performed by sendToPeers until after the request is fully processed, ensuring the client doesn't wait more than the actual processing time for the response.

Periodic timers

Periodic timers will trigger for the first time after timeout, then at best every timeout period after this. Periodic timers may be explicitly stopped by calling the Timer.stop() method on the return value of this function.

As timer are non-preemtive (see the "Preemption" section), user code does not need to compensate for time drift, as the time spent in the function will not affect the frequency, unless the function takes longer to complete than the timer.

Preemption

Like other events in Vibe.d, timers are non-preemptive, meaning that the currently executing function will not be interrupted to let a timer run. This is usually not a problem in server applications, as any blocking code will be easily noticed (the server will stop to handle requests), but might come at a surprise in code that doesn't handle request. If this is a problem, the solution is usually to either explicitly give control to the event loop (by calling yield) or ensuring operations are asynchronous (e.g. call functions from vibe.core.file instead of std.file).

Reentrancy

The event loop guarantees that the same timer will never be called more than once at a time. Hence, functions run on a timer do not need to be re-entrant, even if they execute for longer than the timer frequency.

Parameters

NameDescription
timeout Determines the minimum amount of time that elapses before the timer fires.
callback A delegate to be called when the timer fires. Can be null, in which case the timer will not do anything.
periodic Speficies if the timer fires repeatedly or only once

Returns

Returns a Timer object that can be used to identify and modify the timer.

See also

createTimer

Example

void printTime()
@safe nothrow {
	import std.datetime;
	logInfo("The time is: %s", Clock.currTime());
}

void test()
{
	import vibe.core.core;
	// start a periodic timer that prints the time every second
	setTimer(1.seconds, toDelegate(&printTime), true);
}

Function setTimer

Compatibility overload - use a @safe nothrow callback instead.

Timer setTimer (
  core.time.Duration timeout,
  void delegate() callback,
  bool periodic = false
);
Authors

Sönke Ludwig

Copyright

© 2012-2020 Sönke Ludwig

License

Subject to the terms of the MIT license, as written in the included LICENSE.txt file.