ViewVC Help
View File | Revision Log | Show Annotations | Download File
/cvs/libev/ev.pod
(Generate patch)

Comparing libev/ev.pod (file contents):
Revision 1.27 by root, Wed Nov 14 05:02:07 2007 UTC vs.
Revision 1.28 by root, Sat Nov 17 02:00:49 2007 UTC

… …
472given time, and optionally repeating in regular intervals after that. 472given time, and optionally repeating in regular intervals after that.
473 473
474The timers are based on real time, that is, if you register an event that 474The timers are based on real time, that is, if you register an event that
475times out after an hour and you reset your system clock to last years 475times out after an hour and you reset your system clock to last years
476time, it will still time out after (roughly) and hour. "Roughly" because 476time, it will still time out after (roughly) and hour. "Roughly" because
477detecting time jumps is hard, and soem inaccuracies are unavoidable (the 477detecting time jumps is hard, and some inaccuracies are unavoidable (the
478monotonic clock option helps a lot here). 478monotonic clock option helps a lot here).
479 479
480The relative timeouts are calculated relative to the C<ev_now ()> 480The relative timeouts are calculated relative to the C<ev_now ()>
481time. This is usually the right thing as this timestamp refers to the time 481time. This is usually the right thing as this timestamp refers to the time
482of the event triggering whatever timeout you are modifying/starting. If 482of the event triggering whatever timeout you are modifying/starting. If
483you suspect event processing to be delayed and you *need* to base the timeout 483you suspect event processing to be delayed and you I<need> to base the timeout
484on the current time, use something like this to adjust for this: 484on the current time, use something like this to adjust for this:
485 485
486 ev_timer_set (&timer, after + ev_now () - ev_time (), 0.); 486 ev_timer_set (&timer, after + ev_now () - ev_time (), 0.);
487
488The callback is guarenteed to be invoked only when its timeout has passed,
489but if multiple timers become ready during the same loop iteration then
490order of execution is undefined.
487 491
488=over 4 492=over 4
489 493
490=item ev_timer_init (ev_timer *, callback, ev_tstamp after, ev_tstamp repeat) 494=item ev_timer_init (ev_timer *, callback, ev_tstamp after, ev_tstamp repeat)
491 495
… …
538again). 542again).
539 543
540They can also be used to implement vastly more complex timers, such as 544They can also be used to implement vastly more complex timers, such as
541triggering an event on eahc midnight, local time. 545triggering an event on eahc midnight, local time.
542 546
547As with timers, the callback is guarenteed to be invoked only when the
548time (C<at>) has been passed, but if multiple periodic timers become ready
549during the same loop iteration then order of execution is undefined.
550
543=over 4 551=over 4
544 552
545=item ev_periodic_init (ev_periodic *, callback, ev_tstamp at, ev_tstamp interval, reschedule_cb) 553=item ev_periodic_init (ev_periodic *, callback, ev_tstamp at, ev_tstamp interval, reschedule_cb)
546 554
547=item ev_periodic_set (ev_periodic *, ev_tstamp after, ev_tstamp repeat, reschedule_cb) 555=item ev_periodic_set (ev_periodic *, ev_tstamp after, ev_tstamp repeat, reschedule_cb)
548 556
549Lots of arguments, lets sort it out... There are basically three modes of 557Lots of arguments, lets sort it out... There are basically three modes of
550operation, and we will explain them from simplest to complex: 558operation, and we will explain them from simplest to complex:
551
552 559
553=over 4 560=over 4
554 561
555=item * absolute timer (interval = reschedule_cb = 0) 562=item * absolute timer (interval = reschedule_cb = 0)
556 563

Diff Legend

– Removed lines
+ Added lines
< Changed lines
> Changed lines