--- libev/ev.pod	2009/07/19 01:36:34	1.259
+++ libev/ev.pod	2009/07/19 21:18:03	1.260
@@ -364,6 +364,21 @@
 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_NOSIGNALFD>
+
+When this flag is specified, then libev will not attempt to use the
+I<signalfd> API for it's C<ev_signal> (and C<ev_child>) watchers. This is
+probably only useful to work around any bugs in libev. Consequently, this
+flag might go away once the signalfd functionality is considered stable,
+so it's useful mostly in environment variables and not in program code.
+
 =item C<EVBACKEND_SELECT>  (value 1, portable select backend)
 
 This is your standard select(2) backend. Not I<completely> standard, as
@@ -520,9 +535,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.
 
@@ -2078,17 +2094,20 @@
 will try it's best to deliver signals synchronously, i.e. as part of the
 normal event processing, like any other event.
 
-Note that only the default loop supports registering signal watchers
-currently.
-
-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.
-
-You can configure as many watchers as you like per signal. Only 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).
+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.
+
+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).
 
 Both the signal mask state (C<sigprocmask>) and the signal handler state
 (C<sigaction>) are unspecified after starting a signal watcher (and after
@@ -3801,6 +3820,15 @@
 of the API are still available, and do not complain if this subset changes
 over time.
 
+=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
 
 C<ev_child> watchers use a small hash table to distribute workload by