Browse Source

timer ordering

master
Marc Alexander Lehmann 13 years ago
parent
commit
07e90ea35b
  1. 2
      Changes
  2. 13
      ev.pod

2
Changes

@ -5,6 +5,8 @@ TODO: ev_walk
TODO: ev_stop_all
TODO: fix signal handling(?) under win32
3.54
- multiple timers becoming ready within an event loop iteration
will be invoked in the "correct" order now.
- do not leave the event loop early just because we have no active
watchers, fixing a problem when embedding a kqueue loop
that has active kernel events but no registered watchers

13
ev.pod

@ -1326,8 +1326,10 @@ 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 I<after> its timeout has
passed, but if multiple timers become ready during the same loop iteration
then order of execution is undefined.
passed. If multiple timers become ready during the same loop iteration
then the ones with earlier time-out values are invoked before ones with
later time-out values (but this is no longer true when a callback calls
C<ev_loop> recursively).
=head3 Be smart about timeouts
@ -1626,9 +1628,10 @@ other complicated rules. This cannot be done with C<ev_timer> watchers, as
those cannot react to time jumps.
As with timers, the callback is guaranteed to be invoked only when the
point in time where it is supposed to trigger has passed, but if multiple
periodic timers become ready during the same loop iteration, then order of
execution is undefined.
point in time where it is supposed to trigger has passed. If multiple
timers become ready during the same loop iteration then the ones with
earlier time-out values are invoked before ones with later time-out values
(but this is no longer true when a callback calls C<ev_loop> recursively).
=head3 Watcher-Specific Functions and Data Members

Loading…
Cancel
Save