From a940c598f3ecbfb8b20cd9b568c87f74995e07c8 Mon Sep 17 00:00:00 2001 From: root Date: Mon, 8 Sep 2008 16:36:14 +0000 Subject: *** empty log message *** --- ev.pod | 19 +++++++++++++------ 1 file changed, 13 insertions(+), 6 deletions(-) (limited to 'ev.pod') diff --git a/ev.pod b/ev.pod index 0044dff..b27ab0d 100644 --- a/ev.pod +++ b/ev.pod @@ -1199,18 +1199,25 @@ year, it will still time out after (roughly) and hour. "Roughly" because detecting time jumps is hard, and some inaccuracies are unavoidable (the monotonic clock option helps a lot here). +The callback is guaranteed to be invoked only after its timeout has passed, +but if multiple timers become ready during the same loop iteration then +order of execution is undefined. + +=head3 The special problem of time updates + +Requesting the current time is a costly operation (it usually takes at +least two syscalls): EV therefore updates it's idea of the current time +only before and after C polls for new events, which causes the +difference between C and C. + The relative timeouts are calculated relative to the C time. This is usually the right thing as this timestamp refers to the time of the event triggering whatever timeout you are modifying/starting. If -you suspect event processing to be delayed and you I to base the timeout -on the current time, use something like this to adjust for this: +you suspect event processing to be delayed and you I to base the +timeout on the current time, use something like this to adjust for this: ev_timer_set (&timer, after + ev_now () - ev_time (), 0.); -The callback is guaranteed to be invoked only after its timeout has passed, -but if multiple timers become ready during the same loop iteration then -order of execution is undefined. - =head3 Watcher-Specific Functions and Data Members =over 4 -- cgit v1.2.3