--- libev/ev.pod	2008/11/20 00:35:10	1.218
+++ libev/ev.pod	2009/02/06 20:17:43	1.224
@@ -45,7 +45,7 @@
    main (void)
    {
      // use the default event loop unless you have special needs
-     ev_loop *loop = ev_default_loop (0);
+     struct ev_loop *loop = ev_default_loop (0);
 
      // initialise an io watcher, then start it
      // this one will watch for stdin to become readable
@@ -462,8 +462,8 @@
 everywhere, so you might need to test for this. And since it is broken
 almost everywhere, you should only use it when you have a lot of sockets
 (for which it usually works), by embedding it into another event loop
-(e.g. C<EVBACKEND_SELECT> or C<EVBACKEND_POLL>) and, did I mention it,
-using it only for sockets.
+(e.g. C<EVBACKEND_SELECT> or C<EVBACKEND_POLL> (but C<poll> is of course
+also broken on OS X)) and, did I mention it, using it only for sockets.
 
 This backend maps C<EV_READ> into an C<EVFILT_READ> kevent with
 C<NOTE_EOF>, and C<EV_WRITE> into an C<EVFILT_WRITE> kevent with
@@ -2014,7 +2014,7 @@
 
 For local paths, this usually doesn't matter: unless the system is very
 busy or the intervals between stat's are large, a stat call will be fast,
-as the path data is suually in memory already (except when starting the
+as the path data is usually in memory already (except when starting the
 watcher).
 
 For networked file systems, calling C<stat ()> can block an indefinite
@@ -2430,24 +2430,20 @@
 this case you would put all the high priority stuff in one loop and all
 the rest in a second one, and embed the second one in the first.
 
-As long as the watcher is active, the callback will be invoked every time
-there might be events pending in the embedded loop. The callback must then
-call C<ev_embed_sweep (mainloop, watcher)> to make a single sweep and invoke
-their callbacks (you could also start an idle watcher to give the embedded
-loop strictly lower priority for example). You can also set the callback
-to C<0>, in which case the embed watcher will automatically execute the
-embedded loop sweep.
-
-As long as the watcher is started it will automatically handle events. The
-callback will be invoked whenever some events have been handled. You can
-set the callback to C<0> to avoid having to specify one if you are not
-interested in that.
-
-Also, there have not currently been made special provisions for forking:
-when you fork, you not only have to call C<ev_loop_fork> on both loops,
-but you will also have to stop and restart any C<ev_embed> watchers
-yourself - but you can use a fork watcher to handle this automatically,
-and future versions of libev might do just that.
+As long as the watcher is active, the callback will be invoked every
+time there might be events pending in the embedded loop. The callback
+must then call C<ev_embed_sweep (mainloop, watcher)> to make a single
+sweep and invoke their callbacks (the callback doesn't need to invoke the
+C<ev_embed_sweep> function directly, it could also start an idle watcher
+to give the embedded loop strictly lower priority for example).
+
+You can also set the callback to C<0>, in which case the embed watcher
+will automatically execute the embedded loop sweep whenever necessary.
+
+Fork detection will be handled transparently while the C<ev_embed> watcher
+is active, i.e., the embedded loop will automatically be forked when the
+embedding loop forks. In other cases, the user is responsible for calling
+C<ev_loop_fork> on the embedded loop.
 
 Unfortunately, not all backends are embeddable: only the ones returned by
 C<ev_embeddable_backends> are, which, unfortunately, does not include any
@@ -2893,6 +2889,36 @@
    ev::io iow;
    iow.set <myclass, &myclass::io_cb> (&obj);
 
+=item w->set (object *)
+
+This is an B<experimental> feature that might go away in a future version.
+
+This is a variation of a method callback - leaving out the method to call
+will default the method to C<operator ()>, which makes it possible to use
+functor objects without having to manually specify the C<operator ()> all
+the time. Incidentally, you can then also leave out the template argument
+list.
+
+The C<operator ()> method prototype must be C<void operator ()(watcher &w,
+int revents)>.
+
+See the method-C<set> above for more details.
+
+Example: use a functor object as callback.
+
+   struct myfunctor
+   {
+     void operator() (ev::io &w, int revents)
+     {
+       ...
+     }
+   }
+    
+   myfunctor f;
+
+   ev::io w;
+   w.set (&f);
+
 =item w->set<function> (void *data = 0)
 
 Also sets a callback, but uses a static method or plain function as
@@ -3205,11 +3231,13 @@
 =item EV_USE_REALTIME
 
 If defined to be C<1>, libev will try to detect the availability of the
-real-time clock option at compile time (and assume its availability at
-runtime if successful). Otherwise no use of the real-time clock option will
-be attempted. This effectively replaces C<gettimeofday> by C<clock_get
-(CLOCK_REALTIME, ...)> and will not normally affect correctness. See the
-note about libraries in the description of C<EV_USE_MONOTONIC>, though.
+real-time clock option at compile time (and assume its availability
+at runtime if successful). Otherwise no use of the real-time clock
+option will be attempted. This effectively replaces C<gettimeofday>
+by C<clock_get (CLOCK_REALTIME, ...)> and will not normally affect
+correctness. See the note about libraries in the description of
+C<EV_USE_MONOTONIC>, though. Defaults to the opposite value of
+C<EV_USE_CLOCK_SYSCALL>.
 
 =item EV_USE_CLOCK_SYSCALL
 
@@ -3217,9 +3245,10 @@
 of calling the system-provided C<clock_gettime> function. This option
 exists because on GNU/Linux, C<clock_gettime> is in C<librt>, but C<librt>
 unconditionally pulls in C<libpthread>, slowing down single-threaded
-programs needlessly. Using a direct syscall is slightly slower, because
-no optimised vdso implementation can be used, but avoids the pthread
-dependency. Defaults to C<1> on GNU/Linux with glibc 2.x or higher.
+programs needlessly. Using a direct syscall is slightly slower (in
+theory), because no optimised vdso implementation can be used, but avoids
+the pthread dependency. Defaults to C<1> on GNU/Linux with glibc 2.x or
+higher, as it simplifies linking (no need for C<-lrt>).
 
 =item EV_USE_NANOSLEEP