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

Comparing libev/ev.pod (file contents):
Revision 1.93 by root, Fri Dec 21 01:29:34 2007 UTC vs.
Revision 1.101 by ayin, Sat Dec 22 14:11:25 2007 UTC

 Returns the current time as libev would use it. Please note that the
 C<ev_now> function is usually faster and also often returns the timestamp
 you actually want to know.
+=item ev_sleep (ev_tstamp interval)
+Sleep for the given interval: The current thread will be blocked until
+either it is interrupted or the given time interval has passed. Basically
+this is a subsecond-resolution C<sleep ()>.
 =item int ev_version_major ()
 =item int ev_version_minor ()
 You can find out the major and minor ABI version numbers of the library
 lot of inactive fds). It scales similarly to select, i.e. O(total_fds).
 =item C<EVBACKEND_EPOLL>   (value 4, Linux)
 For few fds, this backend is a bit little slower than poll and select,
-but it scales phenomenally better. While poll and select usually scale like
+but it scales phenomenally better. While poll and select usually scale
-O(total_fds) where n is the total number of fds (or the highest fd), epoll scales
+like O(total_fds) where n is the total number of fds (or the highest fd),
-either O(1) or O(active_fds).
+epoll scales either O(1) or O(active_fds). The epoll design has a number
+of shortcomings, such as silently dropping events in some hard-to-detect
+cases and rewiring a syscall per fd change, no fork support and bad
+support for dup:
-While stopping and starting an I/O watcher in the same iteration will
+While stopping, setting and starting an I/O watcher in the same iteration
-result in some caching, there is still a syscall per such incident
+will result in some caching, there is still a syscall per such incident
 (because the fd could point to a different file description now), so its
-best to avoid that. Also, dup()ed file descriptors might not work very
+best to avoid that. Also, C<dup ()>'ed file descriptors might not work
-well if you register events for both fds.
+very well if you register events for both fds.
 Please note that epoll sometimes generates spurious notifications, so you
 need to use non-blocking I/O or other means to avoid blocking when no data
 (or space) is available.
 =item C<EVBACKEND_KQUEUE>  (value 8, most BSD clones)
 Kqueue deserves special mention, as at the time of this writing, it
-was broken on all BSDs except NetBSD (usually it doesn't work with
+was broken on all BSDs except NetBSD (usually it doesn't work reliably
-anything but sockets and pipes, except on Darwin, where of course it's
+with anything but sockets and pipes, except on Darwin, where of course
-completely useless). For this reason it's not being "autodetected"
+it's completely useless). For this reason it's not being "autodetected"
 unless you explicitly specify it explicitly in the flags (i.e. using
-C<EVBACKEND_KQUEUE>).
+C<EVBACKEND_KQUEUE>) or libev was compiled on a known-to-be-good (-enough)
+system like NetBSD.
+You still can embed kqueue into a normal poll or select backend and use it
+only for sockets (after having made sure that sockets work with kqueue on
+the target platform). See C<ev_embed> watchers for more info.
 It scales in the same way as the epoll backend, but the interface to the
 kernel is more efficient (which says nothing about its actual speed, of
-course). While starting and stopping an I/O watcher does not cause an
+course). While stopping, setting and starting an I/O watcher does never
-extra syscall as with epoll, it still adds up to four event changes per
+cause an extra syscall as with C<EVBACKEND_EPOLL>, it still adds up to
-incident, so its best to avoid that.
+two event changes per incident, support for C<fork ()> is very bad and it
+drops fds silently in similarly hard-to-detect cases.
 =item C<EVBACKEND_DEVPOLL> (value 16, Solaris 8)
 This is not implemented yet (and might never be).
 =item C<EVBACKEND_PORT>    (value 32, Solaris 10)
-This uses the Solaris 10 port mechanism. As with everything on Solaris,
+This uses the Solaris 10 event port mechanism. As with everything on Solaris,
 it's really slow, but it still scales very well (O(active_fds)).
-Please note that solaris ports can result in a lot of spurious
+Please note that solaris event ports can deliver a lot of spurious
 notifications, so you need to use non-blocking I/O or other means to avoid
 blocking when no data (or space) is available.
 =item C<EVBACKEND_ALL>
 Example: For some weird reason, unregister the above signal handler again.
   ev_ref (loop);
   ev_signal_stop (loop, &exitsig);
+=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
+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
+increase efficiency of loop iterations.
+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
+overhead for the actual polling but can deliver many events at once.
+By setting a higher I<io collect interval> you allow libev to spend more
+time collecting I/O events, so you can handle more events per iteration,
+at the cost of increasing latency. Timeouts (both C<ev_periodic> and
+C<ev_timer>) will be not affected. Setting this to a non-null value will
+introduce an additional C<ev_sleep ()> call into most loop iterations.
+Likewise, by setting a higher I<timeout collect interval> you allow libev
+to spend more time collecting timeouts, at the expense of increased
+latency (the watcher callback will be called later). C<ev_io> watchers
+will not be affected. Setting this to a non-null value will not introduce
+any overhead in libev.
+Many (busy) programs can usually benefit by setting the io 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 approsaches the timing granularity of most systems.
 =back
 =head1 ANATOMY OF A WATCHER
 such as poll (fortunately in our Xlib example, Xlib already does this on
 its own, so its quite safe to use).
 =head3 The special problem of disappearing file descriptors
-Some backends (e.g kqueue, epoll) need to be told about closing a file
+Some backends (e.g. kqueue, epoll) need to be told about closing a file
 descriptor (either by calling C<close> explicitly or by any other means,
 such as C<dup>). The reason is that you register interest in some file
 descriptor, but when it goes away, the operating system will silently drop
 this interest. If another file descriptor with the same number then is
 registered with libev, there is no efficient way to see that this is, in
 descriptor even if the file descriptor number itself did not change.
 This is how one would do it normally anyway, the important point is that
 the libev application should not optimise around libev but should leave
 optimisations to libev.
+=head3 The special problem of dup'ed file descriptors
+Some backends (e.g. epoll), cannot register events for file descriptors,
+but only events for the underlying file descriptions. That menas when you
+have C<dup ()>'ed file descriptors and register events for them, only one
+file descriptor might actually receive events.
+There is no workaorund possible except not registering events
+for potentially C<dup ()>'ed file descriptors or to resort to
+C<EVBACKEND_SELECT> or C<EVBACKEND_POLL>.
+=head3 The special problem of fork
+Some backends (epoll, kqueue) do not support C<fork ()> at all or exhibit
+useless behaviour. Libev fully supports fork, but needs to be told about
+it in the child.
+To support fork in your programs, you either have to call
+C<ev_default_fork ()> or C<ev_loop_fork ()> after a fork in the child,
+enable C<EVFLAG_FORKCHECK>, or resort to C<EVBACKEND_SELECT> or
+C<EVBACKEND_POLL>.
 =head3 Watcher-Specific Functions
 =over 4
 It is recommended to give C<ev_check> watchers highest (C<EV_MAXPRI>)
 priority, to ensure that they are being run before any other watchers
 after the poll. Also, C<ev_check> watchers (and C<ev_prepare> watchers,
 too) should not activate ("feed") events into libev. While libev fully
-supports this, they will be called before other C<ev_check> watchers did
+supports this, they will be called before other C<ev_check> watchers
-their job. As C<ev_check> watchers are often used to embed other event
+did their job. As C<ev_check> watchers are often used to embed other
-loops those other event loops might be in an unusable state until their
+(non-libev) event loops those other event loops might be in an unusable
-C<ev_check> watcher ran (always remind yourself to coexist peacefully with
+state until their C<ev_check> watcher ran (always remind yourself to
-others).
+coexist peacefully with others).
 =head3 Watcher-Specific Functions and Data Members
 =over 4
 runtime if successful). Otherwise no use of the realtime clock option will
 be attempted. This effectively replaces C<gettimeofday> by C<clock_get
 (CLOCK_REALTIME, ...)> and will not normally affect correctness. See the
 note about libraries in the description of C<EV_USE_MONOTONIC>, though.
+=item EV_USE_NANOSLEEP
+If defined to be C<1>, libev will assume that C<nanosleep ()> is available
+and will use it for delays. Otherwise it will use C<select ()>.
 =item EV_USE_SELECT
 If undefined or defined to be C<1>, libev will compile in support for the
 C<select>(2) backend. No attempt at autodetection will be done: if no
 other method takes over, select will be it. Otherwise the select backend

Diff Legend

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

Comparing libev/ev.pod (file contents): Revision 1.93 by root, Fri Dec 21 01:29:34 2007 UTC vs. Revision 1.101 by ayin, Sat Dec 22 14:11:25 2007 UTC

Diff Legend

Comparing libev/ev.pod (file contents):
Revision 1.93 by root, Fri Dec 21 01:29:34 2007 UTC vs.
Revision 1.101 by ayin, Sat Dec 22 14:11:25 2007 UTC