--- libev/ev.pod	2008/08/06 07:01:25	1.172
+++ libev/ev.pod	2008/09/08 16:36:14	1.175
@@ -1136,10 +1136,9 @@
 =head3 The special problem of SIGPIPE
 
 While not really specific to libev, it is easy to forget about SIGPIPE:
-when reading from a pipe whose other end has been closed, your program
-gets send a SIGPIPE, which, by default, aborts your program. For most
-programs this is sensible behaviour, for daemons, this is usually
-undesirable.
+when writing to a pipe whose other end has been closed, your program gets
+send a SIGPIPE, which, by default, aborts your program. For most programs
+this is sensible behaviour, for daemons, this is usually undesirable.
 
 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
@@ -1200,18 +1199,25 @@
 detecting time jumps is hard, and some inaccuracies are unavoidable (the
 monotonic clock option helps a lot here).
 
+The callback is guaranteed to be invoked only after its timeout has passed,
+but if multiple timers become ready during the same loop iteration then
+order of execution is undefined.
+
+=head3 The special problem of time updates
+
+Requesting the current time is a costly operation (it usually takes at
+least two syscalls): EV therefore updates it's idea of the current time
+only before and after C<ev_loop> polls for new events, which causes the
+difference between C<ev_now ()> and C<ev_time ()>.
+
 The relative timeouts are calculated relative to the C<ev_now ()>
 time. This is usually the right thing as this timestamp refers to the time
 of the event triggering whatever timeout you are modifying/starting. If
-you suspect event processing to be delayed and you I<need> to base the timeout
-on the current time, use something like this to adjust for this:
+you suspect event processing to be delayed and you I<need> to base the
+timeout on the current time, use something like this to adjust for this:
 
    ev_timer_set (&timer, after + ev_now () - ev_time (), 0.);
 
-The callback is guaranteed to be invoked only after its timeout has passed,
-but if multiple timers become ready during the same loop iteration then
-order of execution is undefined.
-
 =head3 Watcher-Specific Functions and Data Members
 
 =over 4
@@ -1572,6 +1578,13 @@
 event-based approach to child reaping and thus use libev's support for
 that, so other libev users can use C<ev_child> watchers freely.
 
+=head3 Stopping the Child Watcher
+
+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.
+
 =head3 Watcher-Specific Functions and Data Members
 
 =over 4