--- libev/ev.pod	2009/07/14 19:11:31	1.255
+++ libev/ev.pod	2009/11/24 14:46:59	1.273
@@ -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
@@ -364,6 +365,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_NOSIGFD>
+
+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
@@ -397,6 +413,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 +539,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 +595,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 +709,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.
@@ -864,6 +884,11 @@
 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
@@ -1213,6 +1238,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 (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). 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
 
 
@@ -1752,6 +1791,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
@@ -1787,6 +1856,18 @@
 This sounds a bit complicated, see L<Be smart about timeouts>, above, for a
 usage example.
 
+=item 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>
+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
@@ -2031,22 +2112,51 @@
 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 execve
+
+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, you can also ensure that the signal mask is
+not blocking any signals (except temporarily, so thread users watch out)
+by specifying the C<EVFLAG_NOSIGFD> when creating the event loop. This
+is not guaranteed for future versions, however.
 
 =head3 Watcher-Specific Functions and Data Members
 
@@ -2101,8 +2211,8 @@
 =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.
@@ -2122,7 +2232,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
 
@@ -3040,12 +3151,6 @@
 
    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)
 
 Feed an event on the given fd, as if a file descriptor backend detected
@@ -3335,6 +3440,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 (only C<ev_io> and C<ev_timer>), to be found at
+L<http://github.com/brimworks/lua-ev>.
+
 =back
 
 
@@ -3510,7 +3621,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
@@ -3585,7 +3696,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
@@ -3593,6 +3704,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)
@@ -3747,6 +3872,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
@@ -4030,16 +4164,20 @@
 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:
+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);
 
-     wake_up_other_thread_in_some_magic_or_not_so_magic_way ();
-
-     pthread_cond_wait (&u->invoke_cv, &u->lock);
+     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