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

Comparing libev/ev.pod (file contents):
Revision 1.152 by root, Wed May 7 14:45:17 2008 UTC vs.
Revision 1.159 by root, Thu May 22 02:44:57 2008 UTC

 =head1 DESCRIPTION
 The newest version of this document is also available as an html-formatted
 web page you might find easier to navigate when reading it for the first
-time: L<http://cvs.schmorp.de/libev/ev.html>.
+time: L<http://pod.tst.eu/http://cvs.schmorp.de/libev/ev.pod>.
 Libev is an event loop: you register interest in certain events (such as a
 file descriptor being readable or a timeout occurring), and it will manage
 these event sources and provide your program with events.
 To get good performance out of this backend you need a high amount of
 parallelity (most of the file descriptors should be busy). If you are
 writing a server, you should C<accept ()> in a loop to accept as many
 connections as possible during one iteration. You might also want to have
 a look at C<ev_set_io_collect_interval ()> to increase the amount of
-readyness notifications you get per iteration.
+readiness notifications you get per iteration.
 =item C<EVBACKEND_POLL>    (value 2, poll backend, available everywhere except on windows)
 And this is your standard poll(2) backend. It's more complicated
 than select, but handles sparse fds better and has no artificial
 While this backend scales well, it requires one system call per active
 file descriptor per loop iteration. For small and medium numbers of file
 descriptors a "slow" C<EVBACKEND_SELECT> or C<EVBACKEND_POLL> backend
 might perform better.
-On the positive side, ignoring the spurious readyness notifications, this
+On the positive side, ignoring the spurious readiness notifications, this
 backend actually performed to specification in all tests and is fully
 embeddable, which is a rare feat among the OS-specific backends.
 =item C<EVBACKEND_ALL>
 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.
+=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
+them for validity. If anything is found to be inconsistent, it will print
+an error message to standard error and call C<abort ()>.
+This can be used to catch bugs inside libev itself: under normal
+circumstances, this function will never abort as of course libev keeps its
+data structures consistent.
 =back
 =head1 ANATOMY OF A WATCHER
 If you must do this, then force the use of a known-to-be-good backend
 (at the time of this writing, this includes only C<EVBACKEND_SELECT> and
 C<EVBACKEND_POLL>).
 Another thing you have to watch out for is that it is quite easy to
-receive "spurious" readyness notifications, that is your callback might
+receive "spurious" readiness notifications, that is your callback might
 be called with C<EV_READ> but a subsequent C<read>(2) will actually block
 because there is no data. Not only are some backends known to create a
 lot of those (for example solaris ports), it is very easy to get into
 this situation even with a relatively standard program structure. Thus
 it is best to always use non-blocking I/O: An extra C<read>(2) returning
 Timer watchers are simple relative timers that generate an event after a
 given time, and optionally repeating in regular intervals after that.
 The timers are based on real time, that is, if you register an event that
-times out after an hour and you reset your system clock to last years
+times out after an hour and you reset your system clock to january last
-time, it will still time out after (roughly) and hour. "Roughly" because
+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 relative timeouts are calculated relative to the C<ev_now ()>
 time. This is usually the right thing as this timestamp refers to the time
 you suspect event processing to be delayed and you I<need> to base the 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 guarenteed to be invoked only when its timeout has passed,
+The callback is guarenteed 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 Watcher-Specific Functions and Data Members
 =item ev_timer_init (ev_timer *, callback, ev_tstamp after, ev_tstamp repeat)
 =item ev_timer_set (ev_timer *, ev_tstamp after, ev_tstamp repeat)
-Configure the timer to trigger after C<after> seconds. If C<repeat> is
+Configure the timer to trigger after C<after> seconds. If C<repeat>
-C<0.>, then it will automatically be stopped. If it is positive, then the
+is C<0.>, then it will automatically be stopped once the timeout is
-timer will automatically be configured to trigger again C<repeat> seconds
+reached. If it is positive, then the timer will automatically be
-later, again, and again, until stopped manually.
+configured to trigger again C<repeat> seconds later, again, and again,
+until stopped manually.
-The timer itself will do a best-effort at avoiding drift, that is, if you
+The timer itself will do a best-effort at avoiding drift, that is, if
-configure a timer to trigger every 10 seconds, then it will trigger at
+you configure a timer to trigger every 10 seconds, then it will normally
-exactly 10 second intervals. If, however, your program cannot keep up with
+trigger at exactly 10 second intervals. If, however, your program cannot
-the timer (because it takes longer than those 10 seconds to do stuff) the
+keep up with the timer (because it takes longer than those 10 seconds to
-timer will not fire more than once per event loop iteration.
+do stuff) the timer will not fire more than once per event loop iteration.
 =item ev_timer_again (loop, ev_timer *)
 This will act as if the timer timed out and restart it again if it is
 repeating. The exact semantics are:
 Periodic watchers are also timers of a kind, but they are very versatile
 (and unfortunately a bit complex).
 Unlike C<ev_timer>'s, they are not based on real time (or relative time)
 but on wallclock time (absolute time). You can tell a periodic watcher
-to trigger "at" some specific point in time. For example, if you tell a
+to trigger after some specific point in time. For example, if you tell a
 periodic watcher to trigger in 10 seconds (by specifiying e.g. C<ev_now ()
-+ 10.>) and then reset your system clock to the last year, then it will
++ 10.>, that is, an absolute time not a delay) and then reset your system
+clock to january of the previous year, then it will take more than year
-take a year to trigger the event (unlike an C<ev_timer>, which would trigger
+to trigger the event (unlike an C<ev_timer>, which would still trigger
-roughly 10 seconds later).
+roughly 10 seconds later as it uses a relative timeout).
-They can also be used to implement vastly more complex timers, such as
+C<ev_periodic>s can also be used to implement vastly more complex timers,
-triggering an event on each midnight, local time or other, complicated,
+such as triggering an event on each "midnight, local time", or other
-rules.
+complicated, rules.
 As with timers, the callback is guarenteed to be invoked only when the
-time (C<at>) has been passed, but if multiple periodic timers become ready
+time (C<at>) has passed, but if multiple periodic timers become ready
 during the same loop iteration then order of execution is undefined.
 =head3 Watcher-Specific Functions and Data Members
 =over 4
 =over 4
 =item * absolute timer (at = time, interval = reschedule_cb = 0)
-In this configuration the watcher triggers an event at the wallclock time
+In this configuration the watcher triggers an event after the wallclock
-C<at> and doesn't repeat. It will not adjust when a time jump occurs,
+time C<at> has passed and doesn't repeat. It will not adjust when a time
-that is, if it is to be run at January 1st 2011 then it will run when the
+jump occurs, that is, if it is to be run at January 1st 2011 then it will
-system time reaches or surpasses this time.
+run when the system time reaches or surpasses this time.
 =item * 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<at + N * interval> 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:
+time, for example, here is a C<ev_periodic> that triggers each hour, on
+the hour:
    ev_periodic_set (&periodic, 0., 3600., 0);
 This doesn't mean there will always be 3600 seconds in between triggers,
 but only that the the callback will be called when the system time shows a
 C<ev_periodic> will try to run the callback in this mode at the next possible
 time where C<time = at (mod interval)>, regardless of any time jumps.
 For numerical stability it is preferable that the C<at> value is near
 C<ev_now ()> (the current time), but there is no range requirement for
-this value.
+this value, and in fact is often specified as zero.
+Note also that there is an upper limit to how often a timer can fire (cpu
+speed for example), so if C<interval> is very small then timing stability
+will of course detoriate. Libev itself tries to be exact to be about one
+millisecond (if the OS supports it and the machine is fast enough).
 =item * manual reschedule mode (at and interval ignored, reschedule_cb = callback)
 In this mode the values for C<interval> and C<at> are both being
 ignored. Instead, each time the periodic watcher gets scheduled, the
 reschedule callback will be called with the watcher as first, and the
 current time as second argument.
 NOTE: I<This callback MUST NOT stop or destroy any periodic watcher,
-ever, or make any event loop modifications>. If you need to stop it,
+ever, or make ANY event loop modifications whatsoever>.
-return C<now + 1e30> (or so, fudge fudge) and stop it afterwards (e.g. by
-starting an C<ev_prepare> watcher, which is legal).
+If you need to stop it, return C<now + 1e30> (or so, fudge fudge) and stop
+it afterwards (e.g. by starting an C<ev_prepare> watcher, which is the
+only event loop modification you are allowed to do).
-Its prototype is C<ev_tstamp (*reschedule_cb)(struct ev_periodic *w,
+The callback prototype is C<ev_tstamp (*reschedule_cb)(struct ev_periodic
-ev_tstamp now)>, e.g.:
+*w, ev_tstamp now)>, e.g.:
    static ev_tstamp my_rescheduler (struct ev_periodic *w, ev_tstamp now)
    {
      return now + 60.;
    }
 It must return the next time to trigger, based on the passed time value
 (that is, the lowest time value larger than to the second argument). It
 will usually be called just before the callback will be triggered, but
 might be called at other times, too.
-NOTE: I<< This callback must always return a time that is later than the
+NOTE: I<< This callback must always return a time that is higher than or
-passed C<now> value >>. Not even C<now> itself will do, it I<must> be larger.
+equal to the passed C<now> value >>.
 This can be used to create very complex timers, such as a timer that
-triggers on each midnight, local time. To do this, you would calculate the
+triggers on "next midnight, local time". To do this, you would calculate the
 next midnight after C<now> and return the timestamp value for this. How
 you do this is, again, up to you (but it is not trivial, which is the main
 reason I omitted it as an example).
 =back
 calls your callback, which does something. When there is another update
 within the same second, C<ev_stat> will be unable to detect it as the stat
 data does not change.
 The solution to this is to delay acting on a change for slightly more
-than second (or till slightly after the next full second boundary), using
+than a second (or till slightly after the next full second boundary), using
 a roughly one-second-delay C<ev_timer> (e.g. C<ev_timer_set (w, 0., 1.02);
 ev_timer_again (loop, w)>).
 The C<.02> offset is added to work around small timing inconsistencies
 of some operating systems (where the second counter of the current time
 inotify watch id. The default size is C<16> (or C<1> with C<EV_MINIMAL>),
 usually more than enough. If you need to manage thousands of C<ev_stat>
 watchers you might want to increase this value (I<must> be a power of
 two).
+=item EV_USE_4HEAP
+Heaps are not very cache-efficient. To improve the cache-efficiency of the
+timer and periodics heap, libev uses a 4-heap when this symbol is defined
+to C<1>. The 4-heap uses more complicated (longer) code but has
+noticably faster performance with many (thousands) of watchers.
+The default is C<1> unless C<EV_MINIMAL> is set in which case it is C<0>
+(disabled).
+=item EV_HEAP_CACHE_AT
+Heaps are not very cache-efficient. To improve the cache-efficiency of the
+timer and periodics heap, libev can cache the timestamp (I<at>) within
+the heap structure (selected by defining C<EV_HEAP_CACHE_AT> to C<1>),
+which uses 8-12 bytes more per watcher and a few hundred bytes more code,
+but avoids random read accesses on heap changes. This improves performance
+noticably with with many (hundreds) of watchers.
+The default is C<1> unless C<EV_MINIMAL> is set in which case it is C<0>
+(disabled).
+=item EV_VERIFY
+Controls how much internal verification (see C<ev_loop_verify ()>) will
+be done: If set to C<0>, no internal verification code will be compiled
+in. If set to C<1>, then verification code will be compiled in, but not
+called. If set to C<2>, then the internal verification code will be
+called once per loop, which can slow down libev. If set to C<3>, then the
+verification code will be called very frequently, which will slow down
+libev considerably.
+The default is C<1>, unless C<EV_MINIMAL> is set, in which case it will be
+C<0.>
 =item EV_COMMON
 By default, all watchers have a C<void *data> member. By redefining
 this macro to a something else you can include more and other types of
 members. You have to define it each time you include one of the files,
 Due to the many, low, and arbitrary limits on the win32 platform and
 the abysmal performance of winsockets, using a large number of sockets
 is not recommended (and not reasonable). If your program needs to use
 more than a hundred or so sockets, then likely it needs to use a totally
-different implementation for windows, as libev offers the POSIX readyness
+different implementation for windows, as libev offers the POSIX readiness
 notification model, which cannot be implemented efficiently on windows
 (microsoft monopoly games).
 =over 4
 =back
 If you know of other additional requirements drop me a note.
+=head1 VALGRIND
+Valgrind has a special section here because it is a popular tool that is
+highly useful, but valgrind reports are very hard to interpret.
+If you think you found a bug (memory leak, uninitialised data access etc.)
+in libev, then check twice: If valgrind reports something like:
+   ==2274==    definitely lost: 0 bytes in 0 blocks.
+   ==2274==      possibly lost: 0 bytes in 0 blocks.
+   ==2274==    still reachable: 256 bytes in 1 blocks.
+then there is no memory leak. Similarly, under some circumstances,
+valgrind might report kernel bugs as if it were a bug in libev, or it
+might be confused (it is a very good tool, but only a tool).
+If you are unsure about something, feel free to contact the mailing list
+with the full valgrind report and an explanation on why you think this is
+a bug in libev. However, don't be annoyed when you get a brisk "this is
+no bug" answer and take the chance of learning how to interpret valgrind
+properly.
+If you need, for some reason, empty reports from valgrind for your project
+I suggest using suppression lists.
 =head1 AUTHOR
 Marc Lehmann <libev@schmorp.de>.

Diff Legend

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

Comparing libev/ev.pod (file contents): Revision 1.152 by root, Wed May 7 14:45:17 2008 UTC vs. Revision 1.159 by root, Thu May 22 02:44:57 2008 UTC

Diff Legend

Comparing libev/ev.pod (file contents):
Revision 1.152 by root, Wed May 7 14:45:17 2008 UTC vs.
Revision 1.159 by root, Thu May 22 02:44:57 2008 UTC