[ViewVC] Diff of: cvs/libev/ev.pod

Comparing libev/ev.pod (file contents):
Revision 1.170 by root, Sat Jul 5 02:25:40 2008 UTC vs.
Revision 1.178 by root, Sat Sep 13 18:25:50 2008 UTC

 received events and started processing them. This timestamp does not
 change as long as callbacks are being processed, and this is also the base
 time used for relative timers. You can treat it as the timestamp of the
 event occurring (or more correctly, libev finding out about it).
+=item ev_now_update (loop)
+Establishes the current time by querying the kernel, updating the time
+returned by C<ev_now ()> in the progress. This is a costly operation and
+is usually done automatically within C<ev_loop ()>.
+This function is rarely useful, but when some event callback runs for a
+very long time without entering the event loop, updating libev's idea of
+the current time is a good idea.
+See also "The special problem of time updates" in the C<ev_timer> section.
 =item ev_loop (loop, int flags)
 Finally, this is it, the event handler. This function usually is called
 after you initialised all your watchers and you want to start handling
 events.
 Here are the gory details of what C<ev_loop> does:
    - Before the first iteration, call any pending watchers.
    * If EVFLAG_FORKCHECK was used, check for a fork.
-   - If a fork was detected, queue and call all fork watchers.
+   - If a fork was detected (by any means), queue and call all fork watchers.
    - Queue and call all prepare watchers.
-   - If we have been forked, recreate the kernel state.
+   - If we have been forked, detach and recreate the kernel state
+     as to not disturb the other process.
    - Update the kernel state with all outstanding changes.
-   - Update the "event loop time".
+   - Update the "event loop time" (ev_now ()).
    - Calculate for how long to sleep or block, if at all
      (active idle watchers, EVLOOP_NONBLOCK or not having
      any active watchers at all will result in not sleeping).
    - Sleep if the I/O and timer collect interval say so.
    - Block the process, waiting for any events.
    - Queue all outstanding I/O (fd) events.
-   - Update the "event loop time" and do time jump handling.
+   - Update the "event loop time" (ev_now ()), and do time jump adjustments.
    - Queue all outstanding timers.
    - Queue all outstanding periodics.
-   - If no events are pending now, queue all idle watchers.
+   - Unless any events are pending now, queue all idle watchers.
    - Queue all check watchers.
    - Call all queued watchers in reverse order (i.e. check watchers first).
      Signals and child watchers are implemented as I/O watchers, and will
      be handled here by queueing them when their watcher gets executed.
    - If ev_unloop has been called, or EVLOOP_ONESHOT or EVLOOP_NONBLOCK
 anymore.
    ... queue jobs here, make sure they register event watchers as long
    ... as they still have work to do (even an idle watcher will do..)
    ev_loop (my_loop, 0);
-   ... jobs done. yeah!
+   ... jobs done or somebody called unloop. yeah!
 =item ev_unloop (loop, how)
 Can be used to make a call to C<ev_loop> return early (but only after it
 has processed all outstanding events). The C<how> argument must be either
 =item ev_set_io_collect_interval (loop, ev_tstamp interval)
 =item ev_set_timeout_collect_interval (loop, ev_tstamp interval)
 These advanced functions influence the time that libev will spend waiting
-for events. Both are by default C<0>, meaning that libev will try to
+for events. Both time intervals are by default C<0>, meaning that libev
-invoke timer/periodic callbacks and I/O callbacks with minimum latency.
+will try to invoke timer/periodic callbacks and I/O callbacks with minimum
+latency.
 Setting these to a higher value (the C<interval> I<must> be >= C<0>)
-allows libev to delay invocation of I/O and timer/periodic callbacks to
+allows libev to delay invocation of I/O and timer/periodic callbacks
-increase efficiency of loop iterations.
+to increase efficiency of loop iterations (or to increase power-saving
+opportunities).
 The background is that sometimes your program runs just fast enough to
 handle one (or very few) event(s) per loop iteration. While this makes
 the program responsive, it also wastes a lot of CPU time to poll for new
 events, especially with backends like C<select ()> which have a high
 Many (busy) programs can usually benefit by setting the I/O collect
 interval to a value near C<0.1> or so, which is often enough for
 interactive servers (of course not for games), likewise for timeouts. It
 usually doesn't make much sense to set it to a lower value than C<0.01>,
 as this approaches the timing granularity of most systems.
+Setting the I<timeout collect interval> can improve the opportunity for
+saving power, as the program will "bundle" timer callback invocations that
+are "near" in time together, by delaying some, thus reducing the number of
+times the process sleeps and wakes up again. Another useful technique to
+reduce iterations/wake-ups is to use C<ev_periodic> watchers and make sure
+they fire on, say, one-second boundaries only.
 =item ev_loop_verify (loop)
 This function only does something when C<EV_VERIFY> support has been
 compiled in. It tries to go through all internal structures and checks
    {
      struct ev_io io;
      int otherfd;
      void *somedata;
      struct whatever *mostinteresting;
-   }
+   };
+   ...
+   struct my_io w;
+   ev_io_init (&w.io, my_cb, fd, EV_READ);
 And since your callback will be called with a pointer to the watcher, you
 can cast it back to your own type:
    static void my_cb (struct ev_loop *loop, struct ev_io *w_, int revents)
    }
 More interesting and less C-conformant ways of casting your callback type
 instead have been omitted.
-Another common scenario is having some data structure with multiple
+Another common scenario is to use some data structure with multiple
-watchers:
+embedded watchers:
    struct my_biggy
    {
      int some_data;
      ev_timer t1;
      ev_timer t2;
    }
-In this case getting the pointer to C<my_biggy> is a bit more complicated,
+In this case getting the pointer to C<my_biggy> is a bit more
-you need to use C<offsetof>:
+complicated: Either you store the address of your C<my_biggy> struct
+in the C<data> member of the watcher, or you need to use some pointer
+arithmetic using C<offsetof> inside your watchers:
    #include <stddef.h>
    static void
    t1_cb (EV_P_ struct ev_timer *w, int revents)
 C<EVBACKEND_POLL>.
 =head3 The special problem of SIGPIPE
 While not really specific to libev, it is easy to forget about SIGPIPE:
-when reading from a pipe whose other end has been closed, your program
+when writing to a pipe whose other end has been closed, your program gets
-gets send a SIGPIPE, which, by default, aborts your program. For most
+send a SIGPIPE, which, by default, aborts your program. For most programs
-programs this is sensible behaviour, for daemons, this is usually
+this is sensible behaviour, for daemons, this is usually undesirable.
-undesirable.
 So when you encounter spurious, unexplained daemon exits, make sure you
 ignore SIGPIPE (and maybe make sure you log the exit status of your daemon
 somewhere, as that would have given you a big clue).
 times out after an hour and you reset your system clock to January last
 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
+Establishing the current time is a costly operation (it usually takes at
+least two system calls): EV therefore updates its idea of the current
+time only before and after C<ev_loop> polls for new events, which causes
+a growing difference between C<ev_now ()> and C<ev_time ()> when handling
+lots of events.
 The relative timeouts are calculated relative to the C<ev_now ()>
 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<need> to base the timeout
+you suspect event processing to be delayed and you I<need> to base the
-on the current time, use something like this to adjust for this:
+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,
+If the event loop is suspended for a long time, you can also force an
-but if multiple timers become ready during the same loop iteration then
+update of the time returned by C<ev_now ()> by calling C<ev_now_update
-order of execution is undefined.
+()>.
 =head3 Watcher-Specific Functions and Data Members
 =over 4
 handler, you can override it easily by installing your own handler for
 C<SIGCHLD> after initialising the default loop, and making sure the
 default loop never gets destroyed. You are encouraged, however, to use an
 event-based approach to child reaping and thus use libev's support for
 that, so other libev users can use C<ev_child> watchers freely.
+=head3 Stopping the Child Watcher
+Currently, the child watcher never gets stopped, even when the
+child terminates, so normally one needs to stop the watcher in the
+callback. Future versions of libev might stop the watcher automatically
+when a child exit is detected.
 =head3 Watcher-Specific Functions and Data Members
 =over 4
 L<http://rev.rubyforge.org/>.
 =item D
 Leandro Lucarella has written a D language binding (F<ev.d>) for libev, to
-be found at L<http://git.llucax.com.ar/?p=software/ev.d.git;a=summary>.
+be found at L<http://proj.llucax.com.ar/wiki/evd>.
 =back
 =head1 MACRO MAGIC

Diff Legend

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

Comparing libev/ev.pod (file contents): Revision 1.170 by root, Sat Jul 5 02:25:40 2008 UTC vs. Revision 1.178 by root, Sat Sep 13 18:25:50 2008 UTC

Diff Legend

Comparing libev/ev.pod (file contents):
Revision 1.170 by root, Sat Jul 5 02:25:40 2008 UTC vs.
Revision 1.178 by root, Sat Sep 13 18:25:50 2008 UTC