--- libev/ev.pod	2009/06/18 18:16:54	1.242
+++ libev/ev.pod	2009/07/02 12:08:55	1.246
@@ -813,7 +813,9 @@
 time collecting I/O events, so you can handle more events per iteration,
 at the cost of increasing latency. Timeouts (both C<ev_periodic> and
 C<ev_timer>) will be not affected. Setting this to a non-null value will
-introduce an additional C<ev_sleep ()> call into most loop iterations.
+introduce an additional C<ev_sleep ()> call into most loop iterations. The
+sleep time ensures that libev will not poll for I/O events more often then
+once per this interval, on average.
 
 Likewise, by setting a higher I<timeout collect interval> you allow libev
 to spend more time collecting timeouts, at the expense of increased
@@ -825,7 +827,11 @@
 interval to a value near C<0.1> or so, which is often enough for
 interactive servers (of course not for games), likewise for timeouts. It
 usually doesn't make much sense to set it to a lower value than C<0.01>,
-as this approaches the timing granularity of most systems.
+as this approaches the timing granularity of most systems. Note that if
+you do transactions with the outside world and you can't increase the
+parallelity, then this setting will limit your transaction rate (if you
+need to poll once per transaction and the I/O collect interval is 0.01,
+then you can't do more than 100 transations per second).
 
 Setting the I<timeout collect interval> can improve the opportunity for
 saving power, as the program will "bundle" timer callback invocations that
@@ -834,6 +840,12 @@
 reduce iterations/wake-ups is to use C<ev_periodic> watchers and make sure
 they fire on, say, one-second boundaries only.
 
+Example: we only need 0.1s timeout granularity, and we wish not to poll
+more often than 100 times per second:
+
+   ev_set_timeout_collect_interval (EV_DEFAULT_UC_ 0.1);
+   ev_set_io_collect_interval (EV_DEFAULT_UC_ 0.01);
+
 =item ev_loop_verify (loop)
 
 This function only does something when C<EV_VERIFY> support has been
@@ -1525,7 +1537,7 @@
 
 At start:
 
-   ev_timer_init (timer, callback);
+   ev_init (timer, callback);
    timer->repeat = 60.;
    ev_timer_again (loop, timer);
 
@@ -1597,7 +1609,7 @@
 to the current time (meaning we just have some activity :), then call the
 callback, which will "do the right thing" and start the timer:
 
-   ev_timer_init (timer, callback);
+   ev_init (timer, callback);
    last_activity = ev_now (loop);
    callback (loop, timer, EV_TIMEOUT);
 
@@ -2004,8 +2016,8 @@
 has been forked (which implies it might have already exited), as long
 as the event loop isn't entered (or is continued from a watcher), i.e.,
 forking and then immediately registering a watcher for the child is fine,
-but forking and registering a watcher a few event loop iterations later is
-not.
+but forking and registering a watcher a few event loop iterations later or
+in the next callback invocation is not.
 
 Only the default event loop is capable of handling signals, and therefore
 you can only register child watchers in the default event loop.
@@ -2473,7 +2485,7 @@
      adns_beforepoll (ads, fds, &nfd, &timeout, timeval_from (ev_time ()));
 
      /* the callback is illegal, but won't be called as we stop during check */
-     ev_timer_init (&tw, 0, timeout * 1e-3);
+     ev_timer_init (&tw, 0, timeout * 1e-3, 0.);
      ev_timer_start (loop, &tw);
 
      // create one ev_io per pollfd
@@ -4067,7 +4079,9 @@
 The type C<double> is used to represent timestamps. It is required to
 have at least 51 bits of mantissa (and 9 bits of exponent), which is good
 enough for at least into the year 4000. This requirement is fulfilled by
-implementations implementing IEEE 754 (basically all existing ones).
+implementations implementing IEEE 754, which is basically all existing
+ones. With IEEE 754 doubles, you get microsecond accuracy until at least
+2200.
 
 =back