X-Git-Url: https://git.llucax.com/software/libev.git/blobdiff_plain/97157ad66d6312deeafc15a8e80ef6f83f2b0de2..5466167e0504f6fd929074dda89e770d4abfd3c3:/ev.pod diff --git a/ev.pod b/ev.pod index d40456b..3ad52c0 100644 --- a/ev.pod +++ b/ev.pod @@ -488,8 +488,9 @@ usually a better approach for this kind of thing. Here are the gory details of what C does: + - Before the first iteration, call any pending watchers. * If there are no active watchers (reference count is zero), return. - - Queue prepare watchers and then call all outstanding watchers. + - Queue all prepare watchers and then call all outstanding watchers. - If we have been forked, recreate the kernel state. - Update the kernel state with all outstanding changes. - Update the "event loop time". @@ -738,8 +739,9 @@ it. Returns a true value iff the watcher is pending, (i.e. it has outstanding events but its callback has not yet been invoked). As long as a watcher is pending (but not active) you must not call an init function on it (but -C is safe) and you must make sure the watcher is available to -libev (e.g. you cnanot C it). +C is safe), you must not change its priority, and you must +make sure the watcher is available to libev (e.g. you cannot C +it). =item callback ev_cb (ev_TYPE *watcher) @@ -768,6 +770,9 @@ watchers on the same event and make sure one is called first. If you need to suppress invocation when higher priority events are pending you need to look at C watchers, which provide this functionality. +You I change the priority of a watcher as long as it is active or +pending. + The default priority used by watchers when no priority has been set is always C<0>, which is supposed to not be too high and not be too low :). @@ -775,6 +780,18 @@ Setting a priority outside the range of C to C is fine, as long as you do not mind that the priority value you query might or might not have been adjusted to be within valid range. +=item ev_invoke (loop, ev_TYPE *watcher, int revents) + +Invoke the C with the given C and C. Neither +C nor C need to be valid as long as the watcher callback +can deal with that fact. + +=item int ev_clear_pending (loop, ev_TYPE *watcher) + +If the watcher is pending, this function returns clears its pending status +and returns its C bitset (as if its callback was invoked). If the +watcher isn't pending it does nothing and returns C<0>. + =back @@ -1059,11 +1076,11 @@ to trigger "at" some specific point in time. For example, if you tell a periodic watcher to trigger in 10 seconds (by specifiying e.g. C) and then reset your system clock to the last year, then it will take a year to trigger the event (unlike an C, which would trigger -roughly 10 seconds later and of course not if you reset your system time -again). +roughly 10 seconds later). They can also be used to implement vastly more complex timers, such as -triggering an event on eahc midnight, local time. +triggering an event on each midnight, local time or other, complicated, +rules. As with timers, the callback is guarenteed to be invoked only when the time (C) has been passed, but if multiple periodic timers become ready @@ -1080,18 +1097,18 @@ operation, and we will explain them from simplest to complex: =over 4 -=item * absolute timer (interval = reschedule_cb = 0) +=item * absolute timer (at = time, interval = reschedule_cb = 0) In this configuration the watcher triggers an event at the wallclock time C and doesn't repeat. It will not adjust when a time jump occurs, that is, if it is to be run at January 1st 2011 then it will run when the system time reaches or surpasses this time. -=item * non-repeating interval timer (interval > 0, reschedule_cb = 0) +=item * non-repeating interval timer (at = offset, interval > 0, reschedule_cb = 0) In this mode the watcher will always be scheduled to time out at the next -C time (for some integer N) and then repeat, regardless -of any time jumps. +C time (for some integer N, which can also be negative) +and then repeat, regardless of any time jumps. This can be used to create timers that do not drift with respect to system time: @@ -1107,7 +1124,11 @@ Another way to think about it (for the mathematically inclined) is that C will try to run the callback in this mode at the next possible time where C