--- libev/ev.pod	2008/11/13 15:55:38	1.216
+++ libev/ev.pod	2009/04/15 17:49:27	1.229
@@ -11,6 +11,8 @@
    // a single header file is required
    #include <ev.h>
 
+   #include <stdio.h> // for puts
+
    // every watcher type has its own typedef'd struct
    // with the name ev_TYPE
    ev_io stdin_watcher;
@@ -43,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
@@ -460,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
@@ -726,13 +728,15 @@
 from returning, call ev_unref() after starting, and ev_ref() before
 stopping it.
 
-As an example, libev itself uses this for its internal signal pipe: It is
-not visible to the libev user and should not keep C<ev_loop> from exiting
-if no event watchers registered by it are active. It is also an excellent
-way to do this for generic recurring timers or from within third-party
-libraries. Just remember to I<unref after start> and I<ref before stop>
-(but only if the watcher wasn't active before, or was active before,
-respectively).
+As an example, libev itself uses this for its internal signal pipe: It
+is not visible to the libev user and should not keep C<ev_loop> from
+exiting if no event watchers registered by it are active. It is also an
+excellent way to do this for generic recurring timers or from within
+third-party libraries. Just remember to I<unref after start> and I<ref
+before stop> (but only if the watcher wasn't active before, or was active
+before, respectively. Note also that libev might stop watchers itself
+(e.g. non-repeating timers) in which case you have to C<ev_ref>
+in the callback).
 
 Example: Create a signal watcher, but keep it from keeping C<ev_loop>
 running when nothing else is active.
@@ -926,6 +930,11 @@
 
 The given async watcher has been asynchronously notified (see C<ev_async>).
 
+=item C<EV_CUSTOM>
+
+Not ever sent (or otherwise used) by libev itself, but can be freely used
+by libev users to signal watchers (e.g. via C<ev_feed_event>).
+
 =item C<EV_ERROR>
 
 An unspecified error has occurred, the watcher has been stopped. This might
@@ -1596,52 +1605,62 @@
 Periodic watchers are also timers of a kind, but they are very versatile
 (and unfortunately a bit complex).
 
-Unlike C<ev_timer>'s, they are not based on real time (or relative time)
-but on wall clock time (absolute time). You can tell a periodic watcher
-to trigger after some specific point in time. For example, if you tell a
-periodic watcher to trigger in 10 seconds (by specifying e.g. C<ev_now ()
-+ 10.>, that is, an absolute time not a delay) and then reset your system
-clock to January of the previous year, then it will take more than year
-to trigger the event (unlike an C<ev_timer>, which would still trigger
-roughly 10 seconds later as it uses a relative timeout).
-
-C<ev_periodic>s can also be used to implement vastly more complex timers,
-such as triggering an event on each "midnight, local time", or other
-complicated rules.
+Unlike C<ev_timer>, periodic watchers are not based on real time (or
+relative time, the physical time that passes) but on wall clock time
+(absolute time, the thing you can read on your calender or clock). The
+difference is that wall clock time can run faster or slower than real
+time, and time jumps are not uncommon (e.g. when you adjust your
+wrist-watch).
+
+You can tell a periodic watcher to trigger after some specific point
+in time: for example, if you tell a periodic watcher to trigger "in 10
+seconds" (by specifying e.g. C<ev_now () + 10.>, that is, an absolute time
+not a delay) and then reset your system clock to January of the previous
+year, then it will take a year or more to trigger the event (unlike an
+C<ev_timer>, which would still trigger roughly 10 seconds after starting
+it, as it uses a relative timeout).
+
+C<ev_periodic> watchers can also be used to implement vastly more complex
+timers, such as triggering an event on each "midnight, local time", or
+other complicated rules. This cannot be done with C<ev_timer> watchers, as
+those cannot react to time jumps.
 
 As with timers, the callback is guaranteed to be invoked only when the
-time (C<at>) has passed, but if multiple periodic timers become ready
-during the same loop iteration, then order of execution is undefined.
+point in time where it is supposed to trigger has passed, but if multiple
+periodic timers become ready during the same loop iteration, then order of
+execution is undefined.
 
 =head3 Watcher-Specific Functions and Data Members
 
 =over 4
 
-=item ev_periodic_init (ev_periodic *, callback, ev_tstamp at, ev_tstamp interval, reschedule_cb)
+=item ev_periodic_init (ev_periodic *, callback, ev_tstamp offset, ev_tstamp interval, reschedule_cb)
 
-=item ev_periodic_set (ev_periodic *, ev_tstamp after, ev_tstamp repeat, reschedule_cb)
+=item ev_periodic_set (ev_periodic *, ev_tstamp offset, ev_tstamp interval, reschedule_cb)
 
-Lots of arguments, lets sort it out... There are basically three modes of
+Lots of arguments, let's sort it out... There are basically three modes of
 operation, and we will explain them from simplest to most complex:
 
 =over 4
 
-=item * absolute timer (at = time, interval = reschedule_cb = 0)
+=item * absolute timer (offset = absolute time, interval = 0, reschedule_cb = 0)
 
 In this configuration the watcher triggers an event after the wall clock
-time C<at> has passed. It will not repeat and will not adjust when a time
-jump occurs, that is, if it is to be run at January 1st 2011 then it will
-only run when the system clock reaches or surpasses this time.
+time C<offset> has passed. It will not repeat and will not adjust when a
+time jump occurs, that is, if it is to be run at January 1st 2011 then it
+will be stopped and invoked when the system clock reaches or surpasses
+this point in time.
 
-=item * repeating interval timer (at = offset, interval > 0, reschedule_cb = 0)
+=item * repeating interval timer (offset = offset within interval, interval > 0, reschedule_cb = 0)
 
 In this mode the watcher will always be scheduled to time out at the next
-C<at + N * interval> time (for some integer N, which can also be negative)
-and then repeat, regardless of any time jumps.
+C<offset + N * interval> time (for some integer N, which can also be
+negative) and then repeat, regardless of any time jumps. The C<offset>
+argument is merely an offset into the C<interval> periods.
 
 This can be used to create timers that do not drift with respect to the
-system clock, for example, here is a C<ev_periodic> that triggers each
-hour, on the hour:
+system clock, for example, here is an C<ev_periodic> that triggers each
+hour, on the hour (with respect to UTC):
 
    ev_periodic_set (&periodic, 0., 3600., 0);
 
@@ -1652,9 +1671,9 @@
 
 Another way to think about it (for the mathematically inclined) is that
 C<ev_periodic> will try to run the callback in this mode at the next possible
-time where C<time = at (mod interval)>, regardless of any time jumps.
+time where C<time = offset (mod interval)>, regardless of any time jumps.
 
-For numerical stability it is preferable that the C<at> value is near
+For numerical stability it is preferable that the C<offset> value is near
 C<ev_now ()> (the current time), but there is no range requirement for
 this value, and in fact is often specified as zero.
 
@@ -1663,15 +1682,16 @@
 will of course deteriorate. Libev itself tries to be exact to be about one
 millisecond (if the OS supports it and the machine is fast enough).
 
-=item * manual reschedule mode (at and interval ignored, reschedule_cb = callback)
+=item * manual reschedule mode (offset ignored, interval ignored, reschedule_cb = callback)
 
-In this mode the values for C<interval> and C<at> are both being
+In this mode the values for C<interval> and C<offset> are both being
 ignored. Instead, each time the periodic watcher gets scheduled, the
 reschedule callback will be called with the watcher as first, and the
 current time as second argument.
 
-NOTE: I<This callback MUST NOT stop or destroy any periodic watcher,
-ever, or make ANY event loop modifications whatsoever>.
+NOTE: I<This callback MUST NOT stop or destroy any periodic watcher, ever,
+or make ANY other event loop modifications whatsoever, unless explicitly
+allowed by documentation here>.
 
 If you need to stop it, return C<now + 1e30> (or so, fudge fudge) and stop
 it afterwards (e.g. by starting an C<ev_prepare> watcher, which is the
@@ -1711,13 +1731,16 @@
 
 =item ev_tstamp ev_periodic_at (ev_periodic *)
 
-When active, returns the absolute time that the watcher is supposed to
-trigger next.
+When active, returns the absolute time that the watcher is supposed
+to trigger next. This is not the same as the C<offset> argument to
+C<ev_periodic_set>, but indeed works even in interval and manual
+rescheduling modes.
 
 =item ev_tstamp offset [read-write]
 
 When repeating, this contains the offset value, otherwise this is the
-absolute point in time (the C<at> value passed to C<ev_periodic_set>).
+absolute point in time (the C<offset> value passed to C<ev_periodic_set>,
+although libev might modify this value for better numerical stability).
 
 Can be modified any time, but changes only take effect when the periodic
 timer fires or C<ev_periodic_again> is being called.
@@ -2012,7 +2035,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
@@ -2179,7 +2202,7 @@
 
 =over 4
 
-=item ev_idle_init (ev_signal *, callback)
+=item ev_idle_init (ev_idle *, callback)
 
 Initialises and configures the idle watcher - it has no parameters of any
 kind. There is a C<ev_idle_set> macro, but using it is utterly pointless,
@@ -2428,24 +2451,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
@@ -2686,9 +2705,14 @@
 similar contexts (see the discussion of C<EV_ATOMIC_T> in the embedding
 section below on what exactly this means).
 
-This call incurs the overhead of a system call only once per loop iteration,
-so while the overhead might be noticeable, it doesn't apply to repeated
-calls to C<ev_async_send>.
+Note that, as with other watchers in libev, multiple events might get
+compressed into a single callback invocation (another way to look at this
+is that C<ev_async> watchers are level-triggered, set on C<ev_async_send>,
+reset when the event loop detects that).
+
+This call incurs the overhead of a system call only once per event loop
+iteration, so while the overhead might be noticeable, it doesn't apply to
+repeated calls to C<ev_async_send> for the same event loop.
 
 =item bool = ev_async_pending (ev_async *)
 
@@ -2701,8 +2725,10 @@
 it will reset the flag again. C<ev_async_pending> can be used to very
 quickly check whether invoking the loop might be a good idea.
 
-Not that this does I<not> check whether the watcher itself is pending, only
-whether it has been requested to make this watcher pending.
+Not that this does I<not> check whether the watcher itself is pending,
+only whether it has been requested to make this watcher pending: there
+is a time window between the event loop checking and resetting the async
+notification, and the callback being invoked.
 
 =back
 
@@ -2891,6 +2917,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
@@ -2986,11 +3042,7 @@
 =item Python
 
 Python bindings can be found at L<http://code.google.com/p/pyev/>. It
-seems to be quite complete and well-documented. Note, however, that the
-patch they require for libev is outright dangerous as it breaks the ABI
-for everybody else, and therefore, should never be applied in an installed
-libev (if python requires an incompatible ABI then it needs to embed
-libev).
+seems to be quite complete and well-documented.
 
 =item Ruby
 
@@ -2999,6 +3051,14 @@
 more on top of it. It can be found via gem servers. Its homepage is at
 L<http://rev.rubyforge.org/>.
 
+Roger Pack reports that using the link order C<-lws2_32 -lmsvcrt-ruby-190>
+makes rev work even on mingw.
+
+=item Haskell
+
+A haskell binding to libev is available at
+L<http://hackage.haskell.org/cgi-bin/hackage-scripts/package/hlibev>.
+
 =item D
 
 Leandro Lucarella has written a D language binding (F<ev.d>) for libev, to
@@ -3184,24 +3244,40 @@
 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
+configuration, but has to be more conservative.
+
 =item EV_USE_MONOTONIC
 
 If defined to be C<1>, libev will try to detect the availability of the
-monotonic clock option at both compile time and runtime. Otherwise no use
-of the monotonic clock option will be attempted. If you enable this, you
-usually have to link against librt or something similar. Enabling it when
-the functionality isn't available is safe, though, although you have
+monotonic clock option at both compile time and runtime. Otherwise no
+use of the monotonic clock option will be attempted. If you enable this,
+you usually have to link against librt or something similar. Enabling it
+when the functionality isn't available is safe, though, although you have
 to make sure you link against any libraries where the C<clock_gettime>
-function is hiding in (often F<-lrt>).
+function is hiding in (often F<-lrt>). See also C<EV_USE_CLOCK_SYSCALL>.
 
 =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
+
+If defined to be C<1>, libev will try to use a direct syscall instead
+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 (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
 
@@ -3227,11 +3303,11 @@
 
 If defined to C<1>, then the select backend will use the system C<fd_set>
 structure. This is useful if libev doesn't compile due to a missing
-C<NFDBITS> or C<fd_mask> definition or it mis-guesses the bitset layout on
-exotic systems. This usually limits the range of file descriptors to some
-low limit such as 1024 or might have other limitations (winsocket only
-allows 64 sockets). The C<FD_SETSIZE> macro, set before compilation, might
-influence the size of the C<fd_set> used.
+C<NFDBITS> or C<fd_mask> definition or it mis-guesses the bitset layout
+on exotic systems. This usually limits the range of file descriptors to
+some low limit such as 1024 or might have other limitations (winsocket
+only allows 64 sockets). The C<FD_SETSIZE> macro, set before compilation,
+configures the maximum size of the C<fd_set>.
 
 =item EV_SELECT_IS_WINSOCKET