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

Comparing libev/ev.pod (file contents):
Revision 1.268 by root, Sat Aug 29 08:15:11 2009 UTC vs.
Revision 1.303 by root, Thu Oct 14 04:29:34 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
 Libev is very configurable. In this manual the default (and most common)
 configuration will be described, which supports multiple event loops. For
 more info about various configuration options please have a look at
 B<EMBED> section in this manual. If libev was configured without support
 for multiple event loops, then all functions taking an initial argument of
-name C<loop> (which is always of type C<ev_loop *>) will not have
+name C<loop> (which is always of type C<struct ev_loop *>) will not have
 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
 When this flag is specified, then libev will not attempt to use the
 I<inotify> API for it's C<ev_stat> watchers. Apart from debugging and
 testing, this flag can be useful to conserve inotify file descriptors, as
 otherwise each loop using C<ev_stat> watchers consumes one inotify handle.
-=item C<EVFLAG_NOSIGNALFD>
+=item C<EVFLAG_SIGNALFD>
-When this flag is specified, then libev will not attempt to use the
+When this flag is specified, then libev will attempt to use the
-I<signalfd> API for it's C<ev_signal> (and C<ev_child>) watchers. This is
+I<signalfd> API for it's C<ev_signal> (and C<ev_child>) watchers. This API
-probably only useful to work around any bugs in libev. Consequently, this
+delivers signals synchronously, which makes it both faster and might make
-flag might go away once the signalfd functionality is considered stable,
+it possible to get the queued signal data. It can also simplify signal
-so it's useful mostly in environment variables and not in program code.
+handling with threads, as long as you properly block signals in your
+threads that are not interested in handling them.
+Signalfd will not be used by default as this changes your signal mask, and
+there are a lot of shoddy libraries and programs (glib's threadpool for
+example) that can't properly initialise their signal masks.
 =item C<EVBACKEND_SELECT>  (value 1, portable select backend)
 This is your standard select(2) backend. Not I<completely> standard, as
 libev tries to roll its own fd_set with no limits on the number of fds,
 This backend maps C<EV_READ> to C<POLLIN | POLLERR | POLLHUP>, and
 C<EV_WRITE> to C<POLLOUT | POLLERR | POLLHUP>.
 =item C<EVBACKEND_EPOLL>   (value 4, Linux)
+Use the linux-specific epoll(7) interface (for both pre- and post-2.6.9
+kernels).
 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 O(total_fds) where n is the total number of fds (or the highest fd),
 epoll scales either O(1) or O(active_fds).
    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.
 In general it is not advisable to call this function except in the
 rare occasion where you really need to free e.g. the signal handling
 pipe fds. If you need dynamically allocated loops it is better to use
-C<ev_loop_new> and C<ev_loop_destroy>).
+C<ev_loop_new> and C<ev_loop_destroy>.
 =item ev_loop_destroy (loop)
 Like C<ev_default_destroy>, but destroys an event loop created by an
 earlier call to C<ev_loop_new>.
 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)
 Ref/unref can be used to add or remove a reference count on the event
 loop: Every watcher keeps one reference, and as long as the reference
 count is nonzero, C<ev_loop> will not return on its own.
-If you have a watcher you never unregister that should not keep C<ev_loop>
+This is useful when you have a watcher that you never intend to
-from returning, call ev_unref() after starting, and ev_ref() before
+unregister, but that nevertheless should not keep C<ev_loop> from
+returning. In such a case, call C<ev_unref> after starting, and C<ev_ref>
-stopping it.
+before stopping it.
 As an example, libev itself uses this for its internal signal pipe: It
 is not visible to the libev user and should not keep C<ev_loop> from
 exiting if no event watchers registered by it are active. It is also an
 excellent way to do this for generic recurring timers or from within
 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
 While event loop modifications are allowed between invocations of
 C<release> and C<acquire> (that's their only purpose after all), no
 modifications done will affect the event loop, i.e. adding watchers will
 have no effect on the set of file descriptors being watched, or the time
-waited. USe an C<ev_async> watcher to wake up C<ev_loop> when you want it
+waited. Use an C<ev_async> watcher to wake up C<ev_loop> when you want it
 to take note of any changes you made.
 In theory, threads executing C<ev_loop> will be async-cancel safe between
 invocations of C<release> and C<acquire>.
 =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>
    ev_io w;
    ev_init (&w, my_cb);
    ev_io_set (&w, STDIN_FILENO, EV_READ);
-=item C<ev_TYPE_set> (ev_TYPE *, [args])
+=item C<ev_TYPE_set> (ev_TYPE *watcher, [args])
 This macro initialises the type-specific parts of a watcher. You need to
 call C<ev_init> at least once before you call this macro, but you can
 call C<ev_TYPE_set> any number of times. You must not, however, call this
 macro on a watcher that is active (it can be pending, however, which is a
 Example: Initialise and set an C<ev_io> watcher in one step.
    ev_io_init (&w, my_cb, STDIN_FILENO, EV_READ);
-=item C<ev_TYPE_start> (loop *, ev_TYPE *watcher)
+=item C<ev_TYPE_start> (loop, ev_TYPE *watcher)
 Starts (activates) the given watcher. Only active watchers will receive
 events. If the watcher is already active nothing will happen.
 Example: Start the C<ev_io> watcher that is being abused as example in this
 whole section.
    ev_io_start (EV_DEFAULT_UC, &w);
-=item C<ev_TYPE_stop> (loop *, ev_TYPE *watcher)
+=item C<ev_TYPE_stop> (loop, ev_TYPE *watcher)
 Stops the given watcher if active, and clears the pending status (whether
 the watcher was active or not).
 It is possible that stopped watchers are pending - for example,
 =item ev_cb_set (ev_TYPE *watcher, callback)
 Change the callback. You can change the callback at virtually any time
 (modulo threads).
-=item ev_set_priority (ev_TYPE *watcher, priority)
+=item ev_set_priority (ev_TYPE *watcher, int priority)
 =item int ev_priority (ev_TYPE *watcher)
 Set and query the priority of the watcher. The priority is a small
 integer between C<EV_MAXPRI> (default: C<2>) and C<EV_MINPRI>
 returns its C<revents> bitset (as if its callback was invoked). If the
 watcher isn't pending it does nothing and returns C<0>.
 Sometimes it can be useful to "poll" a watcher instead of waiting for its
 callback to be invoked, which can be accomplished with this function.
+=item ev_feed_event (loop, ev_TYPE *watcher, int revents)
+Feeds the given event set into the event loop, as if the specified event
+had happened for the specified watcher (which must be a pointer to an
+initialised but not necessarily started event watcher). Obviously you must
+not free the watcher as long as it has pending events.
+Stopping the watcher, letting libev invoke it, or calling
+C<ev_clear_pending> will clear the pending event, even if the watcher was
+not started in the first place.
+See also C<ev_feed_fd_event> and C<ev_feed_signal_event> for related
+functions that do not need a watcher.
 =back
 =head2 ASSOCIATING CUSTOM DATA WITH A WATCHER
 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
 So when you encounter spurious, unexplained daemon exits, make sure you
 ignore SIGPIPE (and maybe make sure you log the exit status of your daemon
 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 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
+the next iteration again (the connection still exists after all), and
+typically causing the program to loop at 100% CPU usage.
+Unfortunately, the set of errors that cause this issue differs between
+operating systems, there is usually little the app can do to remedy the
+situation, and no known thread-safe method of removing the connection to
+cope with overload is known (to me).
+One of the easiest ways to handle this situation is to just ignore it
+- when the program encounters an overload, it will just loop until the
+situation is over. While this is a form of busy waiting, no OS offers an
+event-based way to handle this situation, so it's the best one can do.
+A better way to handle the situation is to log any errors other than
+C<EAGAIN> and C<EWOULDBLOCK>, making sure not to flood the log with such
+messages, and continue as usual, which at least gives the user an idea of
+what could be wrong ("raise the ulimit!"). For extra points one could stop
+the C<ev_io> watcher on the listening fd "for a while", which reduces CPU
+usage.
+If your program is single-threaded, then you could also keep a dummy file
+descriptor for overload situations (e.g. by opening F</dev/null>), and
+when you run into C<ENFILE> or C<EMFILE>, close it, run C<accept>,
+close that fd, and create a new dummy fd. This will gracefully refuse
+clients under typical overload conditions.
+The last way to handle it is to simply log the error and C<exit>, as
+is often done with C<malloc> failures, but this results in an easy
+opportunity for a DoS attack.
 =head3 Watcher-Specific Functions
 =over 4
      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
 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);
+   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
 C<repeat> value), or reset the running timer to the C<repeat> value.
 This sounds a bit complicated, see L<Be smart about timeouts>, above, for a
 usage example.
-=item ev_timer_remaining (loop, ev_timer *)
+=item ev_tstamp ev_timer_remaining (loop, ev_timer *)
 Returns the remaining time until a timer fires. If the timer is active,
 then this time is relative to the current event loop time, otherwise it's
 the timeout value currently configured.
 That is, after an C<ev_timer_set (w, 5, 7)>, C<ev_timer_remaining> returns
-C<5>. When the timer is started and one second passes, C<ev_timer_remain>
+C<5>. When the timer is started and one second passes, C<ev_timer_remaining>
 will return C<4>. When the timer expires and is restarted, it will return
 roughly C<7> (likely slightly less as callback invocation takes some time,
 too), and so on.
 =item ev_tstamp repeat [read-write]
 Example: Call a callback every hour, or, more precisely, whenever the
 system time is divisible by 3600. The callback invocation times have
 potentially a lot of jitter, but good long-term stability.
    static void
-   clock_cb (struct ev_loop *loop, ev_io *w, int revents)
+   clock_cb (struct ev_loop *loop, ev_periodic *w, int revents)
    {
      ... its now a full hour (UTC, or TAI or whatever your clock follows)
    }
    ev_periodic hourly_tick;
 C<SA_RESTART> (or equivalent) behaviour enabled, so system calls should
 not be unduly interrupted. If you have a problem with system calls getting
 interrupted by signals you can block all signals in an C<ev_check> watcher
 and unblock them in an C<ev_prepare> watcher.
-=head3 The special problem of inheritance over execve
+=head3 The special problem of inheritance over fork/execve/pthread_create
 Both the signal mask (C<sigprocmask>) and the signal disposition
 (C<sigaction>) are unspecified after starting a signal watcher (and after
 stopping it again), that is, libev might or might not block the signal,
 and might or might not set or restore the installed signal handler.
 The simplest way to ensure that the signal mask is reset in the child is
 to install a fork handler with C<pthread_atfork> that resets it. That will
 catch fork calls done by libraries (such as the libc) as well.
-In current versions of libev, you can also ensure that the signal mask is
+In current versions of libev, the signal will not be blocked indefinitely
-not blocking any signals (except temporarily, so thread users watch out)
+unless you use the C<signalfd> API (C<EV_SIGNALFD>). While this reduces
-by specifying the C<EVFLAG_NOSIGNALFD> when creating the event loop. This
+the window of opportunity for problems, it will not go away, as libev
-is not guaranteed for future versions, however.
+I<has> to modify the signal mask, at least temporarily.
+So I can't stress this enough: I<If you do not reset your signal mask when
+you expect it to be empty, you have a race condition in your code>. This
+is not a libev-specific thing, this is true for most event libraries.
 =head3 Watcher-Specific Functions and Data Members
 =over 4
 C<ev_default_fork> cheats and calls it in the wrong process, the fork
 handlers will be invoked, too, of course.
 =head3 The special problem of life after fork - how is it possible?
-Most uses of C<fork()> consist of forking, then some simple calls to ste
+Most uses of C<fork()> consist of forking, then some simple calls to set
 up/change the process environment, followed by a call to C<exec()>. This
 sequence should be handled by libev without any problems.
 This changes when the application actually wants to do event handling
 in the child, or both parent in child, in effect "continuing" after the
 believe me.
 =back
-=head2 C<ev_async> - how to wake up another event loop
+=head2 C<ev_async> - how to wake up an event loop
 In general, you cannot use an C<ev_loop> from multiple threads or other
 asynchronous sources such as signal handlers (as opposed to multiple event
 loops - those are of course safe to use in different threads).
-Sometimes, however, you need to wake up another event loop you do not
+Sometimes, however, you need to wake up an event loop you do not control,
-control, for example because it belongs to another thread. This is what
+for example because it belongs to another thread. This is what C<ev_async>
-C<ev_async> watchers do: as long as the C<ev_async> watcher is active, you
+watchers do: as long as the C<ev_async> watcher is active, you can signal
-can signal it by calling C<ev_async_send>, which is thread- and signal
+it by calling C<ev_async_send>, which is thread- and signal safe.
-safe.
 This functionality is very similar to C<ev_signal> watchers, as signals,
 too, are asynchronous in nature, and signals, too, will be compressed
 (i.e. the number of callback invocations may be less than the number of
 C<ev_async_sent> calls).
 =head3 Queueing
 C<ev_async> does not support queueing of data in any way. The reason
 is that the author does not know of a simple (or any) algorithm for a
 multiple-writer-single-reader queue that works in all cases and doesn't
-need elaborate support such as pthreads.
+need elaborate support such as pthreads or unportable memory access
+semantics.
 That means that if you want to queue data, you have to provide your own
 queue. But at least I can tell you how to implement locking around your
 queue:
 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);
-=item ev_feed_event (struct ev_loop *, watcher *, int revents)
-Feeds the given event set into the event loop, as if the specified event
-had happened for the specified watcher (which must be a pointer to an
-initialised but not necessarily started event watcher).
-=item ev_feed_fd_event (struct ev_loop *, int fd, int revents)
+=item ev_feed_fd_event (loop, int fd, int revents)
 Feed an event on the given fd, as if a file descriptor backend detected
 the given events it.
-=item ev_feed_signal_event (struct ev_loop *loop, int signum)
+=item ev_feed_signal_event (loop, int signum)
 Feed an event as if the given signal occurred (C<loop> must be the default
 loop!).
 =back
 =over 4
 =item ev::TYPE::TYPE ()
-=item ev::TYPE::TYPE (struct ev_loop *)
+=item ev::TYPE::TYPE (loop)
 =item ev::TYPE::~TYPE
 The constructor (optionally) takes an event loop to associate the watcher
 with. If it is omitted, it will use C<EV_DEFAULT>.
    myclass obj;
    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
 Example: Use a plain function as callback.
    static void io_cb (ev::io &w, int revents) { }
    iow.set <io_cb> ();
-=item w->set (struct ev_loop *)
+=item w->set (loop)
 Associates a different C<struct ev_loop> with this watcher. You can only
 do this when the watcher is inactive (and not pending either).
 =item w->set ([arguments])
 Erkki Seppala has written Ocaml bindings for libev, to be found at
 L<http://modeemi.cs.tut.fi/~flux/software/ocaml-ev/>.
 =item Lua
-Brian Maher has written a partial interface to libev
+Brian Maher has written a partial interface to libev for lua (at the
-for lua (only C<ev_io> and C<ev_timer>), to be found at
+time of this writing, only C<ev_io> and C<ev_timer>), to be found at
 L<http://github.com/brimworks/lua-ev>.
 =back
    libev.m4
 =head2 PREPROCESSOR SYMBOLS/MACROS
 Libev can be configured via a variety of preprocessor symbols you have to
-define before including any of its files. The default in the absence of
+define before including (or compiling) any of its files. The default in
-autoconf is documented for every option.
+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 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
-=item EV_STANDALONE
+=item EV_STANDALONE (h)
 Must always be C<1> if you do not use autoconf configuration, which
 keeps libev from including F<config.h>, and it also defines dummy
 implementations for some libevent functions (such as logging, which is not
 supported). It will also not define any of the structs usually found in
 as well as for signal and thread safety in C<ev_async> watchers.
 In the absence of this define, libev will use C<sig_atomic_t volatile>
 (from F<signal.h>), which is usually good enough on most platforms.
-=item EV_H
+=item EV_H (h)
 The name of the F<ev.h> header file used to include it. The default if
 undefined is C<"ev.h"> in F<event.h>, F<ev.c> and F<ev++.h>. This can be
 used to virtually rename the F<ev.h> header file in case of conflicts.
-=item EV_CONFIG_H
+=item EV_CONFIG_H (h)
 If C<EV_STANDALONE> isn't C<1>, this variable can be used to override
 F<ev.c>'s idea of where to find the F<config.h> file, similarly to
 C<EV_H>, above.
-=item EV_EVENT_H
+=item EV_EVENT_H (h)
 Similarly to C<EV_H>, this macro can be used to override F<event.c>'s idea
 of how the F<event.h> header can be found, the default is C<"event.h">.
-=item EV_PROTOTYPES
+=item EV_PROTOTYPES (h)
 If defined to be C<0>, then F<ev.h> will not define any function
 prototypes, but still define all the structs and other symbols. This is
 occasionally useful if you want to provide your own wrapper functions
 around libev functions.
 fine.
 If your embedding application does not need any priorities, defining these
 both to C<0> will save some memory and CPU.
-=item EV_PERIODIC_ENABLE
+=item EV_PERIODIC_ENABLE, EV_IDLE_ENABLE, EV_EMBED_ENABLE, EV_STAT_ENABLE,
+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>, then periodic timers are supported. If
+If undefined or defined to be C<1> (and the platform supports it), then
-defined to be C<0>, then they are not. Disabling them saves a few kB of
+the respective watcher type is supported. If defined to be C<0>, then it
-code.
+is not. Disabling watcher types mainly saves code size.
-=item EV_IDLE_ENABLE
+=item EV_FEATURES
-If undefined or defined to be C<1>, then idle watchers are supported. If
-defined to be C<0>, then they are not. Disabling them saves a few kB of
-code.
-=item EV_EMBED_ENABLE
-If undefined or defined to be C<1>, then embed watchers are supported. If
-defined to be C<0>, then they are not. Embed watchers rely on most other
-watcher types, which therefore must not be disabled.
-=item EV_STAT_ENABLE
-If undefined or defined to be C<1>, then stat watchers are supported. If
-defined to be C<0>, then they are not.
-=item EV_FORK_ENABLE
-If undefined or defined to be C<1>, then fork watchers are supported. If
-defined to be C<0>, then they are not.
-=item EV_ASYNC_ENABLE
-If undefined or defined to be C<1>, then async watchers are supported. If
-defined to be C<0>, then they are not.
-=item EV_MINIMAL
 If you need to shave off some kilobytes of code at the expense of some
-speed (but with the full API), define this symbol to C<1>. Currently this
+speed (but with the full API), you can define this symbol to request
-is used to override some inlining decisions, saves roughly 30% code size
+certain subsets of functionality. The default is to enable all features
-on amd64. It also selects a much smaller 2-heap for timer management over
+that can be enabled on the platform.
-the default 4-heap.
-You can save even more by disabling watcher types you do not need
+A typical way to use this symbol is to define it to C<0> (or to a bitset
-and setting C<EV_MAXPRI> == C<EV_MINPRI>. Also, disabling C<assert>
+with some broad features you want) and then selectively re-enable
-(C<-DNDEBUG>) will usually reduce code size a lot.
+additional parts you want, for example if you want everything minimal,
+but multiple event loop support, async and child watchers and the poll
+backend, use this:
-Defining C<EV_MINIMAL> to C<2> will additionally reduce the core API to
+   #define EV_FEATURES 0
-provide a bare-bones event library. See C<ev.h> for details on what parts
+   #define EV_MULTIPLICITY 1
-of the API are still available, and do not complain if this subset changes
+   #define EV_USE_POLL 1
-over time.
+   #define EV_CHILD_ENABLE 1
+   #define EV_ASYNC_ENABLE 1
+The actual value is a bitset, it can be a combination of the following
+values:
+=over 4
+=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
+code size by roughly 30% on amd64).
+When optimising for size, use of compiler flags such as C<-Os> with
+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 code size
+and can additionally have an effect on the size of data structures at
+runtime.
+=item C<4> - full API configuration
+This enables priorities (sets C<EV_MAXPRI>=2 and C<EV_MINPRI>=-2), and
+enables multiplicity (C<EV_MULTIPLICITY>=1).
+=item C<8> - full API
+This enables a lot of the "lesser used" API functions. See C<ev.h> for
+details on which parts of the API are still available without this
+feature, and do not complain if this subset changes over time.
+=item C<16> - enable all optional watcher types
+Enables all optional watcher types.  If you want to selectively enable
+only some watcher types other than I/O and timers (e.g. prepare,
+embed, async, child...) you can enable them manually by defining
+C<EV_watchertype_ENABLE> to C<1> instead.
+=item C<32> - enable all backends
+This enables all backends - without this feature, you need to enable at
+least one backend manually (C<EV_USE_SELECT> is a good choice).
+=item C<64> - enable OS-specific "helper" APIs
+Enable inotify, eventfd, signalfd and similar OS-specific helper APIs by
+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 code/2.8Kb data to 6.5Kb
+code/0.3Kb data on my GNU/Linux amd64 system, while still giving you I/O
+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.
+=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 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
+enabled.
 =item EV_NSIG
 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
-pid. The default size is C<16> (or C<1> with C<EV_MINIMAL>), usually more
+pid. The default size is C<16> (or C<1> with C<EV_FEATURES> disabled),
-than enough. If you need to manage thousands of children you might want to
+usually more than enough. If you need to manage thousands of children you
-increase this value (I<must> be a power of two).
+might want to increase this value (I<must> be a power of two).
 =item EV_INOTIFY_HASHSIZE
 C<ev_stat> watchers use a small hash table to distribute workload by
-inotify watch id. The default size is C<16> (or C<1> with C<EV_MINIMAL>),
+inotify watch id. The default size is C<16> (or C<1> with C<EV_FEATURES>
-usually more than enough. If you need to manage thousands of C<ev_stat>
+disabled), usually more than enough. If you need to manage thousands of
-watchers you might want to increase this value (I<must> be a power of
+C<ev_stat> watchers you might want to increase this value (I<must> be a
-two).
+power of two).
 =item EV_USE_4HEAP
 Heaps are not very cache-efficient. To improve the cache-efficiency of the
 timer and periodics heaps, libev uses a 4-heap when this symbol is defined
 to C<1>. The 4-heap uses more complicated (longer) code but has noticeably
 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>
+The default is C<1>, unless C<EV_FEATURES> overrides it, in which case it
-(disabled).
+will be C<0>.
 =item EV_HEAP_CACHE_AT
 Heaps are not very cache-efficient. To improve the cache-efficiency of the
 timer and periodics heaps, 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
 noticeably with many (hundreds) of watchers.
-The default is C<1> unless C<EV_MINIMAL> is set in which case it is C<0>
+The default is C<1>, unless C<EV_FEATURES> overrides it, in which case it
-(disabled).
+will be C<0>.
 =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
 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
+The default is C<1>, unless C<EV_FEATURES> overrides it, in which case it
-C<0>.
+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
+this macro to something else you can include more and other types of
 members. You have to define it each time you include one of the files,
 though, and it must be identical each time.
 For example, the perl EV module uses something like this:
 file.
 The usage in rxvt-unicode is simpler. It has a F<ev_cpp.h> header file
 that everybody includes and which overrides some configure choices:
-   #define EV_MINIMAL 1
+   #define EV_FEATURES 8
-   #define EV_USE_POLL 0
+   #define EV_USE_SELECT 1
-   #define EV_MULTIPLICITY 0
-   #define EV_PERIODIC_ENABLE 0
+   #define EV_PREPARE_ENABLE 1
+   #define EV_IDLE_ENABLE 1
-   #define EV_STAT_ENABLE 0
+   #define EV_SIGNAL_ENABLE 1
-   #define EV_FORK_ENABLE 0
+   #define EV_CHILD_ENABLE 1
+   #define EV_USE_STDEXCEPT 0
    #define EV_CONFIG_H <config.h>
-   #define EV_MINPRI 0
-   #define EV_MAXPRI 0
    #include "ev++.h"
 And a F<ev_cpp.C> implementation file that contains libev proper and is compiled:
 maintainable.
 And of course, some compiler warnings are just plain stupid, or simply
 wrong (because they don't actually warn about the condition their message
 seems to warn about). For example, certain older gcc versions had some
-warnings that resulted an extreme number of false positives. These have
+warnings that resulted in an extreme number of false positives. These have
 been fixed, but some people still insist on making code warn-free with
 such buggy versions.
 While libev is written to generate as few warnings as possible,
 "warn-free" code is not a goal, and it is recommended not to build libev
 I suggest using suppression lists.
 =head1 PORTABILITY NOTES
+=head2 GNU/LINUX 32 BIT LIMITATIONS
+GNU/Linux is the only common platform that supports 64 bit file/large file
+interfaces but I<disables> them by default.
+That means that libev compiled in the default environment doesn't support
+files larger than 2GiB or so, which mainly affects C<ev_stat> watchers.
+Unfortunately, many programs try to work around this GNU/Linux issue
+by enabling the large file API, which makes them incompatible with the
+standard libev compiled for their system.
+Likewise, libev cannot enable the large file API itself as this would
+suddenly make it incompatible to the default compile time environment,
+i.e. all programs not using special compile switches.
+=head2 OS/X AND DARWIN BUGS
+The whole thing is a bug if you ask me - basically any system interface
+you touch is broken, whether it is locales, poll, kqueue or even the
+OpenGL drivers.
+=head3 C<kqueue> is buggy
+The kqueue syscall is broken in all known versions - most versions support
+only sockets, many support pipes.
+=head3 C<poll> is buggy
+Instead of fixing C<kqueue>, Apple replaced their (working) C<poll>
+implementation by something calling C<kqueue> internally around the 10.5.6
+release, so now C<kqueue> I<and> C<poll> are broken.
+Libev tries to work around this by neither using C<kqueue> nor C<poll> by
+default on this rotten platform, but of course you cna still ask for them
+when creating a loop.
+=head3 C<select> is buggy
+All that's left is C<select>, and of course Apple found a way to fuck this
+one up as well: On OS/X, C<select> actively limits the number of file
+descriptors you can pass in to 1024 - your program suddenyl crashes when
+you use more.
+There is an undocumented "workaround" for this - defining
+C<_DARWIN_UNLIMITED_SELECT>, which libev tries to use, so select I<should>
+work on OS/X.
+=head2 SOLARIS PROBLEMS AND WORKAROUNDS
+=head3 C<errno> reentrancy
+The default compile environment on Solaris is unfortunately so
+thread-unsafe that you can't even use components/libraries compiled
+without C<-D_REENTRANT> (as long as they use C<errno>), which, of course,
+isn't defined by default.
+If you want to use libev in threaded environments you have to make sure
+it's compiled with C<_REENTRANT> defined.
+=head3 Event port backend
+The scalable event interface for Solaris is called "event ports". Unfortunately,
+this mechanism is very buggy. If you run into high CPU usage, your program
+freezes or you get a large number of spurious wakeups, make sure you have
+all the relevant and latest kernel patches applied. No, I don't know which
+ones, but there are multiple ones.
+If you can't get it to work, you can try running the program with
+C<LIBEV_FLAGS=3> to only allow C<poll> and C<select> backends.
+=head2 AIX POLL BUG
+AIX unfortunately has a broken C<poll.h> header. Libev works around
+this by trying to avoid the poll backend altogether (i.e. it's not even
+compiled in), which normally isn't a big problem as C<select> works fine
+with large bitsets, and AIX is dead anyway.
 =head2 WIN32 PLATFORM LIMITATIONS AND WORKAROUNDS
+=head3 General issues
 Win32 doesn't support any of the standards (e.g. POSIX) that libev
 requires, and its I/O model is fundamentally incompatible with the POSIX
 model. Libev still offers limited functionality on this platform in
 the form of the C<EVBACKEND_SELECT> backend, and only supports socket
 descriptors. This only applies when using Win32 natively, not when using
-e.g. cygwin.
+e.g. cygwin. Actually, it only applies to the microsofts own compilers,
+as every compielr comes with a slightly differently broken/incompatible
+environment.
 Lifting these limitations would basically require the full
-re-implementation of the I/O system. If you are into these kinds of
+re-implementation of the I/O system. If you are into this kind of thing,
-things, then note that glib does exactly that for you in a very portable
+then note that glib does exactly that for you in a very portable way (note
-way (note also that glib is the slowest event library known to man).
+also that glib is the slowest event library known to man).
 There is no supported compilation method available on windows except
 embedding it into other applications.
 Sensible signal handling is officially unsupported by Microsoft - libev
 you do I<not> compile the F<ev.c> or any other embedded source files!):
    #include "evwrap.h"
    #include "ev.c"
-=over 4
-=item The winsocket select function
+=head3 The winsocket C<select> function
 The winsocket C<select> function doesn't follow POSIX in that it
 requires socket I<handles> and not socket I<file descriptors> (it is
 also extremely buggy). This makes select very inefficient, and also
 requires a mapping from file descriptors to socket handles (the Microsoft
    #define EV_SELECT_IS_WINSOCKET 1   /* forces EV_SELECT_USE_FD_SET, too */
 Note that winsockets handling of fd sets is O(n), so you can easily get a
 complexity in the O(n²) range when using win32.
-=item Limited number of file descriptors
+=head3 Limited number of file descriptors
 Windows has numerous arbitrary (and low) limits on things.
 Early versions of winsocket's select only supported waiting for a maximum
 of C<64> handles (probably owning to the fact that all windows kernels
 runtime libraries. This might get you to about C<512> or C<2048> sockets
 (depending on windows version and/or the phase of the moon). To get more,
 you need to wrap all I/O functions and provide your own fd management, but
 the cost of calling select (O(n²)) will likely make this unworkable.
-=back
 =head2 PORTABILITY REQUIREMENTS
 In addition to a working ISO-C implementation and of course the
 backend-specific APIs, libev relies on a few additional extensions:
 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 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
+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.268 by root, Sat Aug 29 08:15:11 2009 UTC vs. Revision 1.303 by root, Thu Oct 14 04:29:34 2010 UTC

Diff Legend

Comparing libev/ev.pod (file contents):
Revision 1.268 by root, Sat Aug 29 08:15:11 2009 UTC vs.
Revision 1.303 by root, Thu Oct 14 04:29:34 2010 UTC