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

Comparing libev/ev.pod (file contents):
Revision 1.287 by root, Tue Mar 16 00:43:22 2010 UTC vs.
Revision 1.292 by sf-exg, Mon Mar 22 09:57:01 2010 UTC

 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
    ev_default_loop (ev_recommended_backends () | EVBACKEND_KQUEUE);
 =item struct ev_loop *ev_loop_new (unsigned int flags)
 Similar to C<ev_default_loop>, but always creates a new event loop that is
-always distinct from the default loop. Unlike the default loop, it cannot
+always distinct from the default loop.
-handle signal and child watchers, and attempts to do so will be greeted by
-undefined behaviour (or a failed assertion if assertions are enabled).
-Note that this function I<is> thread-safe, and the recommended way to use
+Note that this function I<is> thread-safe, and one common way to use
 libev with threads is indeed to create one loop per thread, and using the
 default loop in the "main" or "initial" thread.
 Example: Try to create a event loop that uses epoll and nothing else.
    if (!epoller)
      fatal ("no epoll found here, maybe it hides under your chair");
 =item ev_default_destroy ()
-Destroys the default loop again (frees all memory and kernel state
+Destroys the default loop (frees all memory and kernel state etc.). None
-etc.). None of the active event watchers will be stopped in the normal
+of the active event watchers will be stopped in the normal sense, so
-sense, so e.g. C<ev_is_active> might still return true. It is your
+e.g. C<ev_is_active> might still return true. It is your responsibility to
-responsibility to either stop all watchers cleanly yourself I<before>
+either stop all watchers cleanly yourself I<before> calling this function,
-calling this function, or cope with the fact afterwards (which is usually
+or cope with the fact afterwards (which is usually the easiest thing, you
-the easiest thing, you can just ignore the watchers and/or C<free ()> them
+can just ignore the watchers and/or C<free ()> them for example).
-for example).
 Note that certain global state, such as signal state (and installed signal
 handlers), will not be freed by this function, and related watchers (such
 as signal and child watchers) would need to be stopped manually.
 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.
 =item C<EV_WRITE>
 The file descriptor in the C<ev_io> watcher has become readable and/or
 writable.
-=item C<EV_TIMEOUT>
+=item C<EV_TIMER>
 The C<ev_timer> watcher has timed out.
 =item C<EV_PERIODIC>
 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
 to the current time (meaning we just have some activity :), then call the
 callback, which will "do the right thing" and start the timer:
    ev_init (timer, callback);
    last_activity = ev_now (loop);
-   callback (loop, timer, EV_TIMEOUT);
+   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);
 If C<timeout> is less than 0, then no timeout watcher will be
 started. Otherwise an C<ev_timer> watcher with after = C<timeout> (and
 repeat = 0) will be started. C<0> is a valid timeout.
-The callback has the type C<void (*cb)(int revents, void *arg)> and gets
+The callback has the type C<void (*cb)(int revents, void *arg)> and is
 passed an C<revents> set like normal event callbacks (a combination of
-C<EV_ERROR>, C<EV_READ>, C<EV_WRITE> or C<EV_TIMEOUT>) and the C<arg>
+C<EV_ERROR>, C<EV_READ>, C<EV_WRITE> or C<EV_TIMER>) and the C<arg>
 value passed to C<ev_once>. Note that it is possible to receive I<both>
 a timeout and an io event at the same time - you probably should give io
 events precedence.
 Example: wait up to ten seconds for data to appear on STDIN_FILENO.
    static void stdin_ready (int revents, void *arg)
    {
      if (revents & EV_READ)
        /* stdin might have data for us, joy! */;
-     else if (revents & EV_TIMEOUT)
+     else if (revents & EV_TIMER)
        /* doh, nothing entered */;
    }
    ev_once (STDIN_FILENO, EV_READ, 10., stdin_ready, 0);
 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
 default.
 =back
 Compiling with C<gcc -Os -DEV_STANDALONE -DEV_USE_EPOLL=1 -DEV_FEATURES=0>
-reduces the compiled size of libev from 24.7Kb to 6.5Kb on my GNU/Linux
+reduces the compiled size of libev from 24.7Kb code/2.8Kb data to 6.5Kb
-amd64 system, while still giving you I/O watchers, timers and monotonic
+code/0.3Kb data on my GNU/Linux amd64 system, while still giving you I/O
-clock support.
+watchers, timers and monotonic clock support.
 With an intelligent-enough linker (gcc+binutils are intelligent enough
 when you use C<-Wl,--gc-sections -ffunction-sections>) functions unused by
 your program might be left out as well - a binary starting a timer and an
 I/O watcher then might come out at only 5Kb.
 involves iterating over all running async watchers or all signal numbers.
 =back
+=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> 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
+documentation change.
+=item C<EV_MINIMAL> mechanism replaced by C<EV_FEATURES>
+The preprocessor symbol C<EV_MINIMAL> has been replaced by a different
+mechanism, C<EV_FEATURES>. Programs using C<EV_MINIMAL> usually compile
+and work, but the library code will of course be larger.
+=back
 =head1 GLOSSARY
 =over 4
 =item active
 A change of state of some external event, such as data now being available
 for reading on a file descriptor, time having passed or simply not having
 any other events happening anymore.
 In libev, events are represented as single bits (such as C<EV_READ> or
-C<EV_TIMEOUT>).
+C<EV_TIMER>).
 =item event library
 A software package implementing an event model and loop.

Diff Legend

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

Comparing libev/ev.pod (file contents): Revision 1.287 by root, Tue Mar 16 00:43:22 2010 UTC vs. Revision 1.292 by sf-exg, Mon Mar 22 09:57:01 2010 UTC

Diff Legend

Comparing libev/ev.pod (file contents):
Revision 1.287 by root, Tue Mar 16 00:43:22 2010 UTC vs.
Revision 1.292 by sf-exg, Mon Mar 22 09:57:01 2010 UTC