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

Comparing libev/ev.pod (file contents):
Revision 1.290 by root, Tue Mar 16 18:03:01 2010 UTC vs.
Revision 1.299 by sf-exg, Sat Aug 28 21:42:12 2010 UTC

 While this document tries to be as complete as possible in documenting
 libev, its usage and the rationale behind its design, it is not a tutorial
 on event-based programming, nor will it introduce event-based programming
 with libev.
-Familarity with event based programming techniques in general is assumed
+Familiarity with event based programming techniques in general is assumed
 throughout this document.
 =head1 ABOUT LIBEV
 Libev is an event loop: you register interest in certain events (such as a
 this argument.
 =head2 TIME REPRESENTATION
 Libev represents time as a single floating point number, representing
-the (fractional) number of seconds since the (POSIX) epoch (somewhere
+the (fractional) number of seconds since the (POSIX) epoch (in practise
-near the beginning of 1970, details are complicated, don't ask). This
+somewhere near the beginning of 1970, details are complicated, don't
-type is called C<ev_tstamp>, which is what you should use too. It usually
+ask). This type is called C<ev_tstamp>, which is what you should use
-aliases to the C<double> type in C. When you need to do any calculations
+too. It usually aliases to the C<double> type in C. When you need to do
-on it, you should treat it as some floating point value. Unlike the name
+any calculations on it, you should treat it as some floating point value.
-component C<stamp> might indicate, it is also used for time differences
+Unlike the name component C<stamp> might indicate, it is also used for
-throughout libev.
+time differences (e.g. delays) throughout libev.
 =head1 ERROR HANDLING
 Libev knows three classes of errors: operating system errors, usage errors
 and internal errors (bugs).
 as this indicates an incompatible change. Minor versions are usually
 compatible to older versions, so a larger minor version alone is usually
 not a problem.
 Example: Make sure we haven't accidentally been linked against the wrong
-version.
+version (note, however, that this will not detect ABI mismatches :).
    assert (("libev version mismatch",
             ev_version_major () == EV_VERSION_MAJOR
             && ev_version_minor () >= EV_VERSION_MINOR));
 useful to try out specific backends to test their performance, or to work
 around bugs.
 =item C<EVFLAG_FORKCHECK>
-Instead of calling C<ev_default_fork> or C<ev_loop_fork> manually after
+Instead of calling C<ev_loop_fork> manually after a fork, you can also
-a fork, you can also make libev check for a fork in each iteration by
+make libev check for a fork in each iteration by enabling this flag.
-enabling this flag.
 This works by calling C<getpid ()> on every iteration of the loop,
 and thus this might slow down your event loop if you do a lot of loop
 iterations and little real work, but is usually not noticeable (on my
 GNU/Linux system for example, C<getpid> is actually a simple 5-insn sequence
 name, you can call it anytime, but it makes most sense after forking, in
 the child process (or both child and parent, but that again makes little
 sense). You I<must> call it in the child before using any of the libev
 functions, and it will only take effect at the next C<ev_loop> iteration.
+Again, you I<have> to call it on I<any> loop that you want to re-use after
+a fork, I<even if you do not plan to use the loop in the parent>. This is
+because some kernel interfaces *cough* I<kqueue> *cough* do funny things
+during fork.
 On the other hand, you only need to call this function in the child
-process if and only if you want to use the event library in the child. If
+process if and only if you want to use the event loop in the child. If you
-you just fork+exec, you don't have to call it at all.
+just fork+exec or create a new loop in the child, you don't have to call
+it at all.
 The function itself is quite fast and it's usually not a problem to call
 it just in case after a fork. To make this easy, the function will fit in
 quite nicely into a call to C<pthread_atfork>:
 =item ev_loop_fork (loop)
 Like C<ev_default_fork>, but acts on an event loop created by
 C<ev_loop_new>. Yes, you have to call this on every allocated event loop
-after fork that you want to re-use in the child, and how you do this is
+after fork that you want to re-use in the child, and how you keep track of
-entirely your own problem.
+them is entirely your own problem.
 =item int ev_is_default_loop (loop)
 Returns true when the given loop is, in fact, the default loop, and false
 otherwise.
-=item unsigned int ev_loop_count (loop)
+=item unsigned int ev_iteration (loop)
-Returns the count of loop iterations for the loop, which is identical to
+Returns the current iteration count for the loop, which is identical to
 the number of times libev did poll for new events. It starts at C<0> and
 happily wraps around with enough iterations.
 This value can sometimes be useful as a generation counter of sorts (it
 "ticks" the number of loop iterations), as it roughly corresponds with
-C<ev_prepare> and C<ev_check> calls.
+C<ev_prepare> and C<ev_check> calls - and is incremented between the
+prepare and check phases.
-=item unsigned int ev_loop_depth (loop)
+=item unsigned int ev_depth (loop)
 Returns the number of times C<ev_loop> was entered minus the number of
 times C<ev_loop> was exited, in other words, the recursion depth.
 Outside C<ev_loop>, this number is zero. In a callback, this number is
 C<1>, unless C<ev_loop> was invoked recursively (or from another thread),
 in which case it is higher.
 Leaving C<ev_loop> abnormally (setjmp/longjmp, cancelling the thread
-etc.), doesn't count as exit.
+etc.), doesn't count as "exit" - consider this as a hint to avoid such
+ungentleman behaviour unless it's really convenient.
 =item unsigned int ev_backend (loop)
 Returns one of the C<EVBACKEND_*> flags indicating the event backend in
 use.
 C<ev_resume> directly afterwards to resume timer processing.
 Effectively, all C<ev_timer> watchers will be delayed by the time spend
 between C<ev_suspend> and C<ev_resume>, and all C<ev_periodic> watchers
 will be rescheduled (that is, they will lose any events that would have
-occured while suspended).
+occurred while suspended).
 After calling C<ev_suspend> you B<must not> call I<any> function on the
 given loop other than C<ev_resume>, and you B<must not> call C<ev_resume>
 without a previous call to C<ev_suspend>.
 C<EVUNLOOP_ONE>, which will make the innermost C<ev_loop> call return, or
 C<EVUNLOOP_ALL>, which will make all nested C<ev_loop> calls return.
 This "unloop state" will be cleared when entering C<ev_loop> again.
-It is safe to call C<ev_unloop> from otuside any C<ev_loop> calls.
+It is safe to call C<ev_unloop> from outside any C<ev_loop> calls.
 =item ev_ref (loop)
 =item ev_unref (loop)
 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. Note that if
 you do transactions with the outside world and you can't increase the
 parallelity, then this setting will limit your transaction rate (if you
 need to poll once per transaction and the I/O collect interval is 0.01,
-then you can't do more than 100 transations per second).
+then you can't do more than 100 transactions per second).
 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
 For example, to emulate how many other event libraries handle priorities,
 you can associate an C<ev_idle> watcher to each such watcher, and in
 the normal watcher callback, you just start the idle watcher. The real
 processing is done in the idle watcher callback. This causes libev to
-continously poll and process kernel event data for the watcher, but when
+continuously poll and process kernel event data for the watcher, but when
 the lock-out case is known to be rare (which in turn is rare :), this is
 workable.
 Usually, however, the lock-out model implemented that way will perform
 miserably under the type of load it was designed to handle. In that case,
    {
      // stop the I/O watcher, we received the event, but
      // are not yet ready to handle it.
      ev_io_stop (EV_A_ w);
-     // start the idle watcher to ahndle the actual event.
+     // start the idle watcher to handle the actual event.
      // it will not be executed as long as other watchers
      // with the default priority are receiving events.
      ev_idle_start (EV_A_ &idle);
    }
 If you cannot use non-blocking mode, 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>). The same applies to file
 descriptors for which non-blocking operation makes no sense (such as
-files) - libev doesn't guarentee any specific behaviour in that case.
+files) - libev doesn't guarantee any specific behaviour in that case.
 Another thing you have to watch out for is that it is quite easy to
 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
 somewhere, as that would have given you a big clue).
 =head3 The special problem of accept()ing when you can't
 Many implementations of the POSIX C<accept> function (for example,
-found in port-2004 Linux) have the peculiar behaviour of not removing a
+found in post-2004 Linux) have the peculiar behaviour of not removing a
 connection from the pending queue in all error cases.
 For example, larger servers often run out of file descriptors (because
 of resource limits), causing C<accept> to fail with C<ENFILE> but not
 rejecting the connection, leading to libev signalling readiness on
      ev_tstamp timeout = last_activity + 60.;
      // if last_activity + 60. is older than now, we did time out
      if (timeout < now)
        {
-         // timeout occured, take action
+         // timeout occurred, take action
        }
      else
        {
          // callback was invoked, but there was some activity, re-arm
          // the watcher to fire in last_activity + 60, which is
    callback (loop, timer, EV_TIMER);
 And when there is some activity, simply store the current time in
 C<last_activity>, no libev calls at all:
-   last_actiivty = ev_now (loop);
+   last_activity = ev_now (loop);
 This technique is slightly more complex, but in most cases where the
 time-out is unlikely to be triggered, much more efficient.
 Changing the timeout is trivial as well (if it isn't hard-coded in the
    ev::io iow;
    iow.set <myclass, &myclass::io_cb> (&obj);
 =item w->set (object *)
-This is an B<experimental> feature that might go away in a future version.
 This is a variation of a method callback - leaving out the method to call
 will default the method to C<operator ()>, which makes it possible to use
 functor objects without having to manually specify the C<operator ()> all
 the time. Incidentally, you can then also leave out the template argument
 list.
 define before including (or compiling) any of its files. The default in
 the absence of autoconf is documented for every option.
 Symbols marked with "(h)" do not change the ABI, and can have different
 values when compiling libev vs. including F<ev.h>, so it is permissible
-to redefine them before including F<ev.h> without breakign compatibility
+to redefine them before including F<ev.h> without breaking compatibility
 to a compiled library. All other symbols change the ABI, which means all
 users of libev and the libev code itself must be compiled with compatible
 settings.
 =over 4
 EV_PREPARE_ENABLE, EV_CHECK_ENABLE, EV_FORK_ENABLE, EV_SIGNAL_ENABLE,
 EV_ASYNC_ENABLE, EV_CHILD_ENABLE.
 If undefined or defined to be C<1> (and the platform supports it), then
 the respective watcher type is supported. If defined to be C<0>, then it
-is not. Disabling watcher types mainly saves codesize.
+is not. Disabling watcher types mainly saves code size.
 =item EV_FEATURES
 If you need to shave off some kilobytes of code at the expense of some
 speed (but with the full API), you can define this symbol to request
 =item C<1> - faster/larger code
 Use larger code to speed up some operations.
-Currently this is used to override some inlining decisions (enlarging the  roughly
+Currently this is used to override some inlining decisions (enlarging the
-30% code size on amd64.
+code size by roughly 30% on amd64).
 When optimising for size, use of compiler flags such as C<-Os> with
-gcc recommended, as well as C<-DNDEBUG>, as libev contains a number of
+gcc is recommended, as well as C<-DNDEBUG>, as libev contains a number of
 assertions.
 =item C<2> - faster/larger data structures
 Replaces the small 2-heap for timer management by a faster 4-heap, larger
-hash table sizes and so on. This will usually further increase codesize
+hash table sizes and so on. This will usually further increase code size
 and can additionally have an effect on the size of data structures at
 runtime.
 =item C<4> - full API configuration
 I/O watcher then might come out at only 5Kb.
 =item EV_AVOID_STDIO
 If this is set to C<1> at compiletime, then libev will avoid using stdio
-functions (printf, scanf, perror etc.). This will increase the codesize
+functions (printf, scanf, perror etc.). This will increase the code size
 somewhat, but if your program doesn't otherwise depend on stdio and your
 libc allows it, this avoids linking in the stdio library which is quite
 big.
 Note that error messages might become less precise when this option is
 The highest supported signal number, +1 (or, the number of
 signals): Normally, libev tries to deduce the maximum number of signals
 automatically, but sometimes this fails, in which case it can be
 specified. Also, using a lower number than detected (C<32> should be
-good for about any system in existance) can save some memory, as libev
+good for about any system in existence) can save some memory, as libev
 statically allocates some 12-24 bytes per signal number.
 =item EV_PID_HASHSIZE
 C<ev_child> watchers use a small hash table to distribute workload by
 involves iterating over all running async watchers or all signal numbers.
 =back
-=head1 PORTING FROM 3.X TO 4.X
+=head1 PORTING FROM LIBEV 3.X TO 4.X
 The major version 4 introduced some minor incompatible changes to the API.
+At the moment, the C<ev.h> header file tries to implement superficial
+compatibility, so most programs should still compile. Those might be
+removed in later versions of libev, so better update early than late.
 =over 4
+=item C<ev_loop_count> renamed to C<ev_iteration>
+=item C<ev_loop_depth> renamed to C<ev_depth>
+=item C<ev_loop_verify> renamed to C<ev_verify>
+Most functions working on C<struct ev_loop> objects don't have an
+C<ev_loop_> prefix, so it was removed. Note that C<ev_loop_fork> is
+still called C<ev_loop_fork> because it would otherwise clash with the
+C<ev_fork> typedef.
-=item C<EV_TIMEOUT> replaced by C<EV_TIMER> in C<revents>
+=item C<EV_TIMEOUT> renamed to C<EV_TIMER> in C<revents>
 This is a simple rename - all other watcher types use their name
 as revents flag, and now C<ev_timer> does, too.
 Both C<EV_TIMER> and C<EV_TIMEOUT> symbols were present in 3.x versions
-and continue to be present for the forseeable future, so this is mostly a
+and continue to be present for the foreseeable future, so this is mostly a
 documentation change.
 =item C<EV_MINIMAL> mechanism replaced by C<EV_FEATURES>
 The preprocessor symbol C<EV_MINIMAL> has been replaced by a different

Diff Legend

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

Comparing libev/ev.pod (file contents): Revision 1.290 by root, Tue Mar 16 18:03:01 2010 UTC vs. Revision 1.299 by sf-exg, Sat Aug 28 21:42:12 2010 UTC

Diff Legend

Comparing libev/ev.pod (file contents):
Revision 1.290 by root, Tue Mar 16 18:03:01 2010 UTC vs.
Revision 1.299 by sf-exg, Sat Aug 28 21:42:12 2010 UTC