--- libev/ev.pod	2009/07/08 02:46:05	1.247
+++ libev/ev.pod	2010/03/14 21:05:52	1.284
@@ -100,13 +100,14 @@
 Libev supports C<select>, C<poll>, the Linux-specific C<epoll>, the
 BSD-specific C<kqueue> and the Solaris-specific event port mechanisms
 for file descriptor events (C<ev_io>), the Linux C<inotify> interface
-(for C<ev_stat>), relative timers (C<ev_timer>), absolute timers
-with customised rescheduling (C<ev_periodic>), synchronous signals
-(C<ev_signal>), process status change events (C<ev_child>), and event
-watchers dealing with the event loop mechanism itself (C<ev_idle>,
-C<ev_embed>, C<ev_prepare> and C<ev_check> watchers) as well as
-file watchers (C<ev_stat>) and even limited support for fork events
-(C<ev_fork>).
+(for C<ev_stat>), Linux eventfd/signalfd (for faster and cleaner
+inter-thread wakeup (C<ev_async>)/signal handling (C<ev_signal>)) relative
+timers (C<ev_timer>), absolute timers with customised rescheduling
+(C<ev_periodic>), synchronous signals (C<ev_signal>), process status
+change events (C<ev_child>), and event watchers dealing with the event
+loop mechanism itself (C<ev_idle>, C<ev_embed>, C<ev_prepare> and
+C<ev_check> watchers) as well as file watchers (C<ev_stat>) and even
+limited support for fork events (C<ev_fork>).
 
 It also is quite fast (see this
 L<benchmark|http://libev.schmorp.de/bench.html> comparing it to libevent
@@ -119,7 +120,7 @@
 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
@@ -364,6 +365,26 @@
 This flag setting cannot be overridden or specified in the C<LIBEV_FLAGS>
 environment variable.
 
+=item C<EVFLAG_NOINOTIFY>
+
+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_SIGNALFD>
+
+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 API
+delivers signals synchronously, which makes it both faster and might make
+it possible to get the queued signal data. It can also simplify signal
+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
@@ -397,6 +418,9 @@
 
 =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),
@@ -520,9 +544,10 @@
 
 =back
 
-If one or more of these are or'ed into the flags value, then only these
-backends will be tried (in the reverse order as listed here). If none are
-specified, all backends in C<ev_recommended_backends ()> will be tried.
+If one or more of the backend flags are or'ed into the flags value,
+then only these backends will be tried (in the reverse order as listed
+here). If none are specified, all backends in C<ev_recommended_backends
+()> will be tried.
 
 Example: This is the most typical usage.
 
@@ -575,7 +600,7 @@
 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)
 
@@ -689,8 +714,8 @@
 =item ev_loop (loop, int flags)
 
 Finally, this is it, the event handler. This function usually is called
-after you initialised all your watchers and you want to start handling
-events.
+after you have initialised all your watchers and you want to start
+handling events.
 
 If the flags argument is specified as C<0>, it will not return until
 either no event watchers are active anymore or C<ev_unloop> was called.
@@ -774,9 +799,10 @@
 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>
-from returning, call ev_unref() after starting, and ev_ref() before
-stopping it.
+This is useful when you have a watcher that you never intend to
+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>
+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
@@ -858,6 +884,71 @@
    ev_set_timeout_collect_interval (EV_DEFAULT_UC_ 0.1);
    ev_set_io_collect_interval (EV_DEFAULT_UC_ 0.01);
 
+=item ev_invoke_pending (loop)
+
+This call will simply invoke all pending watchers while resetting their
+pending state. Normally, C<ev_loop> does this automatically when required,
+but when overriding the invoke callback this call comes handy.
+
+=item int ev_pending_count (loop)
+
+Returns the number of pending watchers - zero indicates that no watchers
+are pending.
+
+=item ev_set_invoke_pending_cb (loop, void (*invoke_pending_cb)(EV_P))
+
+This overrides the invoke pending functionality of the loop: Instead of
+invoking all pending watchers when there are any, C<ev_loop> will call
+this callback instead. This is useful, for example, when you want to
+invoke the actual watchers inside another context (another thread etc.).
+
+If you want to reset the callback, use C<ev_invoke_pending> as new
+callback.
+
+=item ev_set_loop_release_cb (loop, void (*release)(EV_P), void (*acquire)(EV_P))
+
+Sometimes you want to share the same loop between multiple threads. This
+can be done relatively simply by putting mutex_lock/unlock calls around
+each call to a libev function.
+
+However, C<ev_loop> can run an indefinite time, so it is not feasible to
+wait for it to return. One way around this is to wake up the loop via
+C<ev_unloop> and C<av_async_send>, another way is to set these I<release>
+and I<acquire> callbacks on the loop.
+
+When set, then C<release> will be called just before the thread is
+suspended waiting for new events, and C<acquire> is called just
+afterwards.
+
+Ideally, C<release> will just call your mutex_unlock function, and
+C<acquire> will just call the mutex_lock function again.
+
+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
+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>.
+
+See also the locking example in the C<THREADS> section later in this
+document.
+
+=item ev_set_userdata (loop, void *data)
+
+=item ev_userdata (loop)
+
+Set and retrieve a single C<void *> associated with a loop. When
+C<ev_set_userdata> has never been called, then C<ev_userdata> returns
+C<0.>
+
+These two functions can be used to associate arbitrary data with a loop,
+and are intended solely for the C<invoke_pending_cb>, C<release> and
+C<acquire> callbacks described above, but of course can be (ab-)used for
+any other purpose as well.
+
 =item ev_loop_verify (loop)
 
 This function only does something when C<EV_VERIFY> support has been
@@ -1043,7 +1134,7 @@
    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
@@ -1066,7 +1157,7 @@
 
    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.
@@ -1076,7 +1167,7 @@
 
    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).
@@ -1111,7 +1202,7 @@
 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)
 
@@ -1153,6 +1244,20 @@
 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
 
 
@@ -1435,6 +1540,44 @@
 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 port-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
 
@@ -1494,8 +1637,8 @@
 passed (not I<at>, so on systems with very low-resolution clocks this
 might introduce a small delay). If multiple timers become ready during the
 same loop iteration then the ones with earlier time-out values are invoked
-before ones with later time-out values (but this is no longer true when a
-callback calls C<ev_loop> recursively).
+before ones of the same priority with later time-out values (but this is
+no longer true when a callback calls C<ev_loop> recursively).
 
 =head3 Be smart about timeouts
 
@@ -1692,6 +1835,36 @@
 update of the time returned by C<ev_now ()> by calling C<ev_now_update
 ()>.
 
+=head3 The special problems of suspended animation
+
+When you leave the server world it is quite customary to hit machines that
+can suspend/hibernate - what happens to the clocks during such a suspend?
+
+Some quick tests made with a Linux 2.6.28 indicate that a suspend freezes
+all processes, while the clocks (C<times>, C<CLOCK_MONOTONIC>) continue
+to run until the system is suspended, but they will not advance while the
+system is suspended. That means, on resume, it will be as if the program
+was frozen for a few seconds, but the suspend time will not be counted
+towards C<ev_timer> when a monotonic clock source is used. The real time
+clock advanced as expected, but if it is used as sole clocksource, then a
+long suspend would be detected as a time jump by libev, and timers would
+be adjusted accordingly.
+
+I would not be surprised to see different behaviour in different between
+operating systems, OS versions or even different hardware.
+
+The other form of suspend (job control, or sending a SIGSTOP) will see a
+time jump in the monotonic clocks and the realtime clock. If the program
+is suspended for a very long time, and monotonic clock sources are in use,
+then you can expect C<ev_timer>s to expire as the full suspension time
+will be counted towards the timers. When no monotonic clock source is in
+use, then libev will again assume a timejump and adjust accordingly.
+
+It might be beneficial for this latter case to call C<ev_suspend>
+and C<ev_resume> in code that handles C<SIGTSTP>, to at least get
+deterministic behaviour in this case (you can do nothing against
+C<SIGSTOP>).
+
 =head3 Watcher-Specific Functions and Data Members
 
 =over 4
@@ -1727,6 +1900,18 @@
 This sounds a bit complicated, see L<Be smart about timeouts>, above, for a
 usage example.
 
+=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_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]
 
 The current C<repeat> value. Will be used each time the watcher times out
@@ -1971,22 +2156,55 @@
 will try it's best to deliver signals synchronously, i.e. as part of the
 normal event processing, like any other event.
 
-If you want signals asynchronously, just use C<sigaction> as you would
-do without libev and forget about sharing the signal. You can even use
-C<ev_async> from a signal handler to synchronously wake up an event loop.
+If you want signals to be delivered truly asynchronously, just use
+C<sigaction> as you would do without libev and forget about sharing
+the signal. You can even use C<ev_async> from a signal handler to
+synchronously wake up an event loop.
+
+You can configure as many watchers as you like for the same signal, but
+only within the same loop, i.e. you can watch for C<SIGINT> in your
+default loop and for C<SIGIO> in another loop, but you cannot watch for
+C<SIGINT> in both the default loop and another loop at the same time. At
+the moment, C<SIGCHLD> is permanently tied to the default loop.
 
-You can configure as many watchers as you like per signal. Only when the
-first watcher gets started will libev actually register a signal handler
+When the first watcher gets started will libev actually register something
 with the kernel (thus it coexists with your own signal handlers as long as
-you don't register any with libev for the same signal). Similarly, when
-the last signal watcher for a signal is stopped, libev will reset the
-signal handler to SIG_DFL (regardless of what it was set to before).
+you don't register any with libev for the same signal).
 
 If possible and supported, libev will install its handlers with
-C<SA_RESTART> 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.
+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 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.
+
+While this does not matter for the signal disposition (libev never
+sets signals to C<SIG_IGN>, so handlers will be reset to C<SIG_DFL> on
+C<execve>), this matters for the signal mask: many programs do not expect
+certain signals to be blocked.
+
+This means that before calling C<exec> (from the child) you should reset
+the signal mask to whatever "default" you expect (all clear is a good
+choice usually).
+
+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, the signal will not be blocked indefinitely
+unless you use the C<signalfd> API (C<EV_SIGNALFD>). While this reduces
+the window of opportunity for problems, it will not go away, as libev
+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
 
@@ -2034,11 +2252,15 @@
 Only the default event loop is capable of handling signals, and therefore
 you can only register child watchers in the default event loop.
 
+Due to some design glitches inside libev, child watchers will always be
+handled at maximum priority (their priority is set to C<EV_MAXPRI> by
+libev)
+
 =head3 Process Interaction
 
 Libev grabs C<SIGCHLD> as soon as the default event loop is
-initialised. This is necessary to guarantee proper behaviour even if
-the first child watcher is started after the child exits. The occurrence
+initialised. This is necessary to guarantee proper behaviour even if the
+first child watcher is started after the child exits. The occurrence
 of C<SIGCHLD> is recorded asynchronously, but child reaping is done
 synchronously as part of the event loop processing. Libev always reaps all
 children, even ones not watched.
@@ -2058,7 +2280,8 @@
 Currently, the child watcher never gets stopped, even when the
 child terminates, so normally one needs to stop the watcher in the
 callback. Future versions of libev might stop the watcher automatically
-when a child exit is detected.
+when a child exit is detected (calling C<ev_child_stop> twice is not a
+problem).
 
 =head3 Watcher-Specific Functions and Data Members
 
@@ -2808,7 +3031,8 @@
 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
@@ -2976,18 +3200,12 @@
 
    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!).
@@ -3077,7 +3295,7 @@
 
 =item ev::TYPE::TYPE ()
 
-=item ev::TYPE::TYPE (struct ev_loop *)
+=item ev::TYPE::TYPE (loop)
 
 =item ev::TYPE::~TYPE
 
@@ -3164,7 +3382,7 @@
    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).
@@ -3271,6 +3489,12 @@
 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 for lua (at the
+time of this writing, only C<ev_io> and C<ev_timer>), to be found at
+L<http://github.com/brimworks/lua-ev>.
+
 =back
 
 
@@ -3433,12 +3657,19 @@
 =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
-autoconf is documented for every option.
+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 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
@@ -3446,7 +3677,7 @@
 supported). It will also not define any of the structs usually found in
 F<event.h> that are not directly supported by the libev core alone.
 
-In stanbdalone mode, libev will still try to automatically deduce the
+In standalone mode, libev will still try to automatically deduce the
 configuration, but has to be more conservative.
 
 =item EV_USE_MONOTONIC
@@ -3521,7 +3752,7 @@
 it is assumed that all these functions actually work on fds, even
 on win32. Should not be defined on non-win32 platforms.
 
-=item EV_FD_TO_WIN32_HANDLE
+=item EV_FD_TO_WIN32_HANDLE(fd)
 
 If C<EV_SELECT_IS_WINSOCKET> is enabled, then libev needs a way to map
 file descriptors to socket handles. When not defining this symbol (the
@@ -3529,6 +3760,20 @@
 correct. In some cases, programs use their own file descriptor management,
 in which case they can provide this function to map fds to socket handles.
 
+=item EV_WIN32_HANDLE_TO_FD(handle)
+
+If C<EV_SELECT_IS_WINSOCKET> then libev maps handles to file descriptors
+using the standard C<_open_osfhandle> function. For programs implementing
+their own fd to handle mapping, overwriting this function makes it easier
+to do so. This can be done by defining this macro to an appropriate value.
+
+=item EV_WIN32_CLOSE_FD(fd)
+
+If programs implement their own fd to handle mapping on win32, then this
+macro can be used to override the C<close> function, useful to unregister
+file descriptors again. Note that the replacement function has to close
+the underlying OS handle.
+
 =item EV_USE_POLL
 
 If defined to be C<1>, libev will compile in support for the C<poll>(2)
@@ -3584,24 +3829,24 @@
 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
@@ -3633,45 +3878,92 @@
 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
-
-If undefined or defined to be C<1>, then periodic timers are supported. If
-defined to be C<0>, then they are not. Disabling them saves a few kB of
-code.
+=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> (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.
 
-=item EV_IDLE_ENABLE
-
-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
+=item EV_MINIMAL
 
-If undefined or defined to be C<1>, then fork watchers are supported. If
-defined to be C<0>, then they are not.
+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
+is used to override some inlining decisions, saves roughly 30% code size
+on amd64. It also selects a much smaller 2-heap for timer management over
+the default 4-heap.
+
+You can save even more by disabling watcher types you do not need
+and setting C<EV_MAXPRI> == C<EV_MINPRI>. Also, disabling C<assert>
+(C<-DNDEBUG>) will usually reduce code size a lot. Disabling inotify,
+eventfd and signalfd will further help, and disabling backends one doesn't
+need (e.g. poll, epoll, kqueue, ports) will help further.
+
+Defining C<EV_MINIMAL> to C<2> will additionally reduce the core API to
+provide a bare-bones event library. See C<ev.h> for details on what parts
+of the API are still available, and do not complain if this subset changes
+over time.
+
+This example set of settings reduces the compiled size of libev from
+23.9Kb to 7.7Kb on my GNU/Linux amd64 system (and leaves little
+in - there is also an effect on the amount of memory used). With
+an intelligent-enough linker (gcc+binutils do this when you use
+C<-Wl,--gc-sections -ffunction-sections>) further unused functions might
+be left out as well automatically - a binary starting a timer and an I/O
+watcher then might come out at only 5Kb.
 
-=item EV_ASYNC_ENABLE
+   // tuning and API changes
+   #define EV_MINIMAL 2
+   #define EV_MULTIPLICITY 0
+   #define EV_MINPRI 0
+   #define EV_MAXPRI 0
 
-If undefined or defined to be C<1>, then async watchers are supported. If
-defined to be C<0>, then they are not.
+   // OS-specific backends
+   #define EV_USE_INOTIFY 0
+   #define EV_USE_EVENTFD 0
+   #define EV_USE_SIGNALFD 0
+   #define EV_USE_REALTIME 0
+   #define EV_USE_MONOTONIC 0
+   #define EV_USE_CLOCK_SYSCALL 0
 
-=item EV_MINIMAL
+   // disable all backends except select
+   #define EV_USE_POLL 0
+   #define EV_USE_PORT 0
+   #define EV_USE_KQUEUE 0
+   #define EV_USE_EPOLL 0
 
-If you need to shave off some kilobytes of code at the expense of some
-speed, define this symbol to C<1>. Currently this is used to override some
-inlining decisions, saves roughly 30% code size on amd64. It also selects a
-much smaller 2-heap for timer management over the default 4-heap.
+   // disable all watcher types that cna be disabled
+   #define EV_STAT_ENABLE 0
+   #define EV_PERIODIC_ENABLE 0
+   #define EV_IDLE_ENABLE 0
+   #define EV_CHECK_ENABLE 0
+   #define EV_PREPARE_ENABLE 0
+   #define EV_FORK_ENABLE 0
+   #define EV_SIGNAL_ENABLE 0
+   #define EV_CHILD_ENABLE 0
+   #define EV_ASYNC_ENABLE 0
+   #define EV_EMBED_ENABLE 0
+
+=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
+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
+statically allocates some 12-24 bytes per signal number.
 
 =item EV_PID_HASHSIZE
 
@@ -3867,14 +4159,152 @@
 
 =back
 
+=head4 THREAD LOCKING EXAMPLE
+
+Here is a fictitious example of how to run an event loop in a different
+thread than where callbacks are being invoked and watchers are
+created/added/removed.
+
+For a real-world example, see the C<EV::Loop::Async> perl module,
+which uses exactly this technique (which is suited for many high-level
+languages).
+
+The example uses a pthread mutex to protect the loop data, a condition
+variable to wait for callback invocations, an async watcher to notify the
+event loop thread and an unspecified mechanism to wake up the main thread.
+
+First, you need to associate some data with the event loop:
+
+   typedef struct {
+     mutex_t lock; /* global loop lock */
+     ev_async async_w;
+     thread_t tid;
+     cond_t invoke_cv;
+   } userdata;
+
+   void prepare_loop (EV_P)
+   {
+      // for simplicity, we use a static userdata struct.
+      static userdata u;
+
+      ev_async_init (&u->async_w, async_cb);
+      ev_async_start (EV_A_ &u->async_w);
+
+      pthread_mutex_init (&u->lock, 0);
+      pthread_cond_init (&u->invoke_cv, 0);
+
+      // now associate this with the loop
+      ev_set_userdata (EV_A_ u);
+      ev_set_invoke_pending_cb (EV_A_ l_invoke);
+      ev_set_loop_release_cb (EV_A_ l_release, l_acquire);
+
+      // then create the thread running ev_loop
+      pthread_create (&u->tid, 0, l_run, EV_A);
+   }
+
+The callback for the C<ev_async> watcher does nothing: the watcher is used
+solely to wake up the event loop so it takes notice of any new watchers
+that might have been added:
+
+   static void
+   async_cb (EV_P_ ev_async *w, int revents)
+   {
+      // just used for the side effects
+   }
+
+The C<l_release> and C<l_acquire> callbacks simply unlock/lock the mutex
+protecting the loop data, respectively.
+
+   static void
+   l_release (EV_P)
+   {
+     userdata *u = ev_userdata (EV_A);
+     pthread_mutex_unlock (&u->lock);
+   }
+
+   static void
+   l_acquire (EV_P)
+   {
+     userdata *u = ev_userdata (EV_A);
+     pthread_mutex_lock (&u->lock);
+   }
+
+The event loop thread first acquires the mutex, and then jumps straight
+into C<ev_loop>:
+
+   void *
+   l_run (void *thr_arg)
+   {
+     struct ev_loop *loop = (struct ev_loop *)thr_arg;
+
+     l_acquire (EV_A);
+     pthread_setcanceltype (PTHREAD_CANCEL_ASYNCHRONOUS, 0);
+     ev_loop (EV_A_ 0);
+     l_release (EV_A);
+
+     return 0;
+   }
+
+Instead of invoking all pending watchers, the C<l_invoke> callback will
+signal the main thread via some unspecified mechanism (signals? pipe
+writes? C<Async::Interrupt>?) and then waits until all pending watchers
+have been called (in a while loop because a) spurious wakeups are possible
+and b) skipping inter-thread-communication when there are no pending
+watchers is very beneficial):
+
+   static void
+   l_invoke (EV_P)
+   {
+     userdata *u = ev_userdata (EV_A);
+
+     while (ev_pending_count (EV_A))
+       {
+         wake_up_other_thread_in_some_magic_or_not_so_magic_way ();
+         pthread_cond_wait (&u->invoke_cv, &u->lock);
+       }
+   }
+
+Now, whenever the main thread gets told to invoke pending watchers, it
+will grab the lock, call C<ev_invoke_pending> and then signal the loop
+thread to continue:
+
+   static void
+   real_invoke_pending (EV_P)
+   {
+     userdata *u = ev_userdata (EV_A);
+
+     pthread_mutex_lock (&u->lock);
+     ev_invoke_pending (EV_A);
+     pthread_cond_signal (&u->invoke_cv);
+     pthread_mutex_unlock (&u->lock);
+   }
+
+Whenever you want to start/stop a watcher or do other modifications to an
+event loop, you will now have to lock:
+
+   ev_timer timeout_watcher;
+   userdata *u = ev_userdata (EV_A);
+
+   ev_timer_init (&timeout_watcher, timeout_cb, 5.5, 0.);
+
+   pthread_mutex_lock (&u->lock);
+   ev_timer_start (EV_A_ &timeout_watcher);
+   ev_async_send (EV_A_ &u->async_w);
+   pthread_mutex_unlock (&u->lock);
+
+Note that sending the C<ev_async> watcher is required because otherwise
+an event loop currently blocking in the kernel will have no knowledge
+about the newly added timer. By waking up the loop it will pick up any new
+watchers in the next event loop iteration.
+
 =head3 COROUTINES
 
 Libev is very accommodating to coroutines ("cooperative threads"):
 libev fully supports nesting calls to its functions from different
 coroutines (e.g. you can call C<ev_loop> on the same loop from two
-different coroutines, and switch freely between both coroutines running the
-loop, as long as you don't confuse yourself). The only exception is that
-you must not do this from C<ev_periodic> reschedule callbacks.
+different coroutines, and switch freely between both coroutines running
+the loop, as long as you don't confuse yourself). The only exception is
+that you must not do this from C<ev_periodic> reschedule callbacks.
 
 Care has been taken to ensure that libev does not keep local state inside
 C<ev_loop>, and other calls do not usually allow for coroutine switches as