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

Comparing libev/ev.pod (file contents):
Revision 1.366 by sf-exg, Thu Feb 3 16:21:08 2011 UTC vs.
Revision 1.369 by root, Mon May 30 18:34:28 2011 UTC

… …
483=item C<EVBACKEND_EPOLL> (value 4, Linux) 483=item C<EVBACKEND_EPOLL> (value 4, Linux)
484 484
485Use the linux-specific epoll(7) interface (for both pre- and post-2.6.9 485Use the linux-specific epoll(7) interface (for both pre- and post-2.6.9
486kernels). 486kernels).
487 487
488For few fds, this backend is a bit little slower than poll and select, 488For few fds, this backend is a bit little slower than poll and select, but
489but it scales phenomenally better. While poll and select usually scale 489it scales phenomenally better. While poll and select usually scale like
490like O(total_fds) where n is the total number of fds (or the highest fd), 490O(total_fds) where total_fds is the total number of fds (or the highest
491epoll scales either O(1) or O(active_fds). 491fd), epoll scales either O(1) or O(active_fds).
492 492
493The epoll mechanism deserves honorable mention as the most misdesigned 493The epoll mechanism deserves honorable mention as the most misdesigned
494of the more advanced event mechanisms: mere annoyances include silently 494of the more advanced event mechanisms: mere annoyances include silently
495dropping file descriptors, requiring a system call per change per file 495dropping file descriptors, requiring a system call per change per file
496descriptor (and unnecessary guessing of parameters), problems with dup, 496descriptor (and unnecessary guessing of parameters), problems with dup,
… …
825This is useful if you are waiting for some external event in conjunction 825This is useful if you are waiting for some external event in conjunction
826with something not expressible using other libev watchers (i.e. "roll your 826with something not expressible using other libev watchers (i.e. "roll your
827own C<ev_run>"). However, a pair of C<ev_prepare>/C<ev_check> watchers is 827own C<ev_run>"). However, a pair of C<ev_prepare>/C<ev_check> watchers is
828usually a better approach for this kind of thing. 828usually a better approach for this kind of thing.
829 829
830Here are the gory details of what C<ev_run> does: 830Here are the gory details of what C<ev_run> does (this is for your
831understanding, not a guarantee that things will work exactly like this in
832future versions):
831 833
832 - Increment loop depth. 834 - Increment loop depth.
833 - Reset the ev_break status. 835 - Reset the ev_break status.
834 - Before the first iteration, call any pending watchers. 836 - Before the first iteration, call any pending watchers.
835 LOOP: 837 LOOP:
… …
2151 2153
2152Another way to think about it (for the mathematically inclined) is that 2154Another way to think about it (for the mathematically inclined) is that
2153C<ev_periodic> will try to run the callback in this mode at the next possible 2155C<ev_periodic> will try to run the callback in this mode at the next possible
2154time where C<time = offset (mod interval)>, regardless of any time jumps. 2156time where C<time = offset (mod interval)>, regardless of any time jumps.
2155 2157
2156For numerical stability it is preferable that the C<offset> value is near 2158The C<interval> I<MUST> be positive, and for numerical stability, the
2157C<ev_now ()> (the current time), but there is no range requirement for 2159interval value should be higher than C<1/8192> (which is around 100
2158this value, and in fact is often specified as zero. 2160microseconds) and C<offset> should be higher than C<0> and should have
2161at most a similar magnitude as the current time (say, within a factor of
2162ten). Typical values for offset are, in fact, C<0> or something between
2163C<0> and C<interval>, which is also the recommended range.
2159 2164
2160Note also that there is an upper limit to how often a timer can fire (CPU 2165Note also that there is an upper limit to how often a timer can fire (CPU
2161speed for example), so if C<interval> is very small then timing stability 2166speed for example), so if C<interval> is very small then timing stability
2162will of course deteriorate. Libev itself tries to be exact to be about one 2167will of course deteriorate. Libev itself tries to be exact to be about one
2163millisecond (if the OS supports it and the machine is fast enough). 2168millisecond (if the OS supports it and the machine is fast enough).
… …
4204F<event.h> that are not directly supported by the libev core alone. 4209F<event.h> that are not directly supported by the libev core alone.
4205 4210
4206In standalone mode, libev will still try to automatically deduce the 4211In standalone mode, libev will still try to automatically deduce the
4207configuration, but has to be more conservative. 4212configuration, but has to be more conservative.
4208 4213
4214=item EV_USE_FLOOR
4215
4216If defined to be C<1>, libev will use the C<floor ()> function for its
4217periodic reschedule calculations, otherwise libev will fall back on a
4218portable (slower) implementation. If you enable this, you usually have to
4219link against libm or something equivalent. Enabling this when the C<floor>
4220function is not available will fail, so the safe default is to not enable
4221this.
4222
4209=item EV_USE_MONOTONIC 4223=item EV_USE_MONOTONIC
4210 4224
4211If defined to be C<1>, libev will try to detect the availability of the 4225If defined to be C<1>, libev will try to detect the availability of the
4212monotonic clock option at both compile time and runtime. Otherwise no 4226monotonic clock option at both compile time and runtime. Otherwise no
4213use of the monotonic clock option will be attempted. If you enable this, 4227use of the monotonic clock option will be attempted. If you enable this,

Diff Legend

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