--- libev/ev.pod	2011/12/20 16:32:21	1.391
+++ libev/ev.pod	2012/04/02 23:14:41	1.399
@@ -569,9 +569,9 @@
 kernel is more efficient (which says nothing about its actual speed, of
 course). While stopping, setting and starting an I/O watcher does never
 cause an extra system call as with C<EVBACKEND_EPOLL>, it still adds up to
-two event changes per incident. Support for C<fork ()> is very bad (but
-sane, unlike epoll) and it drops fds silently in similarly hard-to-detect
-cases
+two event changes per incident. Support for C<fork ()> is very bad (you
+might have to leak fd's on fork, but it's more sane than epoll) and it
+drops fds silently in similarly hard-to-detect cases
 
 This backend usually performs well under most conditions.
 
@@ -794,18 +794,22 @@
 Calling C<ev_suspend>/C<ev_resume> has the side effect of updating the
 event loop time (see C<ev_now_update>).
 
-=item ev_run (loop, int flags)
+=item bool ev_run (loop, int flags)
 
 Finally, this is it, the event handler. This function usually is called
 after you have initialised all your watchers and you want to start
 handling events. It will ask the operating system for any new events, call
-the watcher callbacks, an then repeat the whole process indefinitely: This
+the watcher callbacks, and then repeat the whole process indefinitely: This
 is why event loops are called I<loops>.
 
 If the flags argument is specified as C<0>, it will keep handling events
 until either no event watchers are active anymore or C<ev_break> was
 called.
 
+The return value is false if there are no more active watchers (which
+usually means "all jobs done" or "deadlock"), and true in all other cases
+(which usually means " you should call C<ev_run> again").
+
 Please note that an explicit C<ev_break> is usually better than
 relying on all watchers to be stopped when deciding when a program has
 finished (especially in interactive programs), but having a program
@@ -813,8 +817,8 @@
 of relying on its watchers stopping correctly, that is truly a thing of
 beauty.
 
-This function is also I<mostly> exception-safe - you can break out of
-a C<ev_run> call by calling C<longjmp> in a callback, throwing a C++
+This function is I<mostly> exception-safe - you can break out of a
+C<ev_run> call by calling C<longjmp> in a callback, throwing a C++
 exception and so on. This does not decrement the C<ev_depth> value, nor
 will it clear any outstanding C<EVBREAK_ONE> breaks.
 
@@ -1880,7 +1884,7 @@
      else
        {
          // callback was invoked, but there was some recent 
-         // activity.  simply restart the timer to time out
+         // activity. simply restart the timer to time out
          // after "after" seconds, which is the earliest time
          // the timeout can occur.
          ev_timer_set (w, after, 0.);
@@ -2110,15 +2114,24 @@
 
 =item ev_timer_again (loop, ev_timer *)
 
-This will act as if the timer timed out and restarts it again if it is
-repeating. The exact semantics are:
+This will act as if the timer timed out, and restarts it again if it is
+repeating. It basically works like calling C<ev_timer_stop>, updating the
+timeout to the C<repeat> value and calling C<ev_timer_start>.
+
+The exact semantics are as in the following rules, all of which will be
+applied to the watcher:
+
+=over 4
+
+=item If the timer is pending, the pending status is always cleared.
 
-If the timer is pending, its pending status is cleared.
+=item If the timer is started but non-repeating, stop it (as if it timed
+out, without invoking it).
 
-If the timer is started but non-repeating, stop it (as if it timed out).
+=item If the timer is repeating, make the C<repeat> value the new timeout
+and start the timer, if necessary.
 
-If the timer is repeating, either start it if necessary (with the
-C<repeat> value), or reset the running timer to the C<repeat> value.
+=back
 
 This sounds a bit complicated, see L<Be smart about timeouts>, above, for a
 usage example.
@@ -3910,6 +3923,10 @@
 you need support for other types of functors please contact the author
 (preferably after implementing it).
 
+For all this to work, your C++ compiler either has to use the same calling
+conventions as your C compiler (for static member functions), or you have
+to embed libev and compile libev itself as C++.
+
 Here is a list of things available in the C<ev> namespace:
 
 =over 4
@@ -4497,6 +4514,19 @@
 be detected at runtime. If undefined, it will be enabled if the headers
 indicate GNU/Linux + Glibc 2.4 or newer, otherwise disabled.
 
+=item EV_NO_SMP
+
+If defined to be C<1>, libev will assume that memory is always coherent
+between threads, that is, threads can be used, but threads never run on
+different cpus (or different cpu cores). This reduces dependencies
+and makes libev faster.
+
+=item EV_NO_THREADS
+
+If defined to be C<1>, libev will assume that it will never be called
+from different threads, which is a stronger assumption than C<EV_NO_SMP>,
+above. This reduces dependencies and makes libev faster.
+
 =item EV_ATOMIC_T
 
 Libev requires an integer type (suitable for storing C<0> or C<1>) whose
@@ -4665,6 +4695,9 @@
 To use this, define C<EV_API_STATIC> and include F<ev.c> in the file that
 wants to use libev.
 
+This option only works when libev is compiled with a C compiler, as C++
+doesn't support the required declaration syntax.
+
 =item EV_AVOID_STDIO
 
 If this is set to C<1> at compiletime, then libev will avoid using stdio