--- libev/ev.pod	2009/04/16 07:56:05	1.236
+++ libev/ev.pod	2009/04/21 14:14:19	1.239
@@ -124,12 +124,12 @@
 
 =head2 TIME REPRESENTATION
 
-Libev represents time as a single floating point number, representing the
-(fractional) number of seconds since the (POSIX) epoch (somewhere near
-the beginning of 1970, details are complicated, don't ask). This type is
-called C<ev_tstamp>, which is what you should use too. It usually aliases
-to the C<double> type in C, and when you need to do any calculations on
-it, you should treat it as some floating point value. Unlike the name
+Libev represents time as a single floating point number, representing
+the (fractional) number of seconds since the (POSIX) epoch (somewhere
+near the beginning of 1970, details are complicated, don't ask). This
+type is called C<ev_tstamp>, which is what you should use too. It usually
+aliases to the C<double> type in C. When you need to do any calculations
+on it, you should treat it as some floating point value. Unlike the name
 component C<stamp> might indicate, it is also used for time differences
 throughout libev.
 
@@ -646,7 +646,7 @@
 very long time without entering the event loop, updating libev's idea of
 the current time is a good idea.
 
-See also "The special problem of time updates" in the C<ev_timer> section.
+See also L<The special problem of time updates> in the C<ev_timer> section.
 
 =item ev_suspend (loop)
 
@@ -1334,7 +1334,9 @@
 
 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>).
+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.
 
 Another thing you have to watch out for is that it is quite easy to
 receive "spurious" readiness notifications, that is your callback might
@@ -2710,6 +2712,39 @@
 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
+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
+fork.
+
+The default mode of operation (for libev, with application help to detect
+forks) is to duplicate all the state in the child, as would be expected
+when I<either> the parent I<or> the child process continues.
+
+When both processes want to continue using libev, then this is usually the
+wrong result. In that case, usually one process (typically the parent) is
+supposed to continue with all watchers in place as before, while the other
+process typically wants to start fresh, i.e. without any active watchers.
+
+The cleanest and most efficient way to achieve that with libev is to
+simply create a new event loop, which of course will be "empty", and
+use that for new watchers. This has the advantage of not touching more
+memory than necessary, and thus avoiding the copy-on-write, and the
+disadvantage of having to use multiple event loops (which do not support
+signal watchers).
+
+When this is not possible, or you want to use the default loop for
+other reasons, then in the process that wants to start "fresh", call
+C<ev_default_destroy ()> followed by C<ev_default_loop (...)>. Destroying
+the default loop will "orphan" (not stop) all registered watchers, so you
+have to be careful not to execute code that modifies those watchers. Note
+also that in that case, you have to re-register any signal watchers.
+
 =head3 Watcher-Specific Functions and Data Members
 
 =over 4