[ViewVC] Diff of: cvs/libev/ev.pod

Comparing libev/ev.pod (file contents):
Revision 1.361 by root, Sun Jan 23 18:53:06 2011 UTC vs.
Revision 1.367 by root, Sun Feb 20 02:56:23 2011 UTC

      ev_timer_start (loop, &timeout_watcher);
      // now wait for events to arrive
      ev_run (loop, 0);
-     // unloop was called, so exit
+     // break was called, so exit
      return 0;
    }
 =head1 ABOUT THIS DOCUMENT
 anymore.
    ... queue jobs here, make sure they register event watchers as long
    ... as they still have work to do (even an idle watcher will do..)
    ev_run (my_loop, 0);
-   ... jobs done or somebody called unloop. yeah!
+   ... jobs done or somebody called break. yeah!
 =item ev_break (loop, how)
 Can be used to make a call to C<ev_run> return early (but only after it
 has processed all outstanding events). The C<how> argument must be either
 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 = offset (mod interval)>, regardless of any time jumps.
-For numerical stability it is preferable that the C<offset> value is near
+The C<interval> I<MUST> be positive, and for numerical stability, the
-C<ev_now ()> (the current time), but there is no range requirement for
+interval value should be higher than C<1/8192> (which is around 100
-this value, and in fact is often specified as zero.
+microseconds) and C<offset> should be higher than C<0> and should have
+at most a similar magnitude as the current time (say, within a factor of
+ten). Typical values for offset are, in fact, C<0> or something between
+C<0> and C<interval>, which is also the recommended range.
 Note also that there is an upper limit to how often a timer can fire (CPU
 speed for example), so if C<interval> is very small then timing stability
 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).
    atexit (program_exits);
 =head2 C<ev_async> - how to wake up an event loop
-In general, you cannot use an C<ev_run> from multiple threads or other
+In general, you cannot use an C<ev_loop> from multiple threads or other
 asynchronous sources such as signal handlers (as opposed to multiple event
 loops - those are of course safe to use in different threads).
 Sometimes, however, you need to wake up an event loop you do not control,
 for example because it belongs to another thread. This is what C<ev_async>
 trust me.
 =item ev_async_send (loop, ev_async *)
 Sends/signals/activates the given C<ev_async> watcher, that is, feeds
-an C<EV_ASYNC> event on the watcher into the event loop. Unlike
+an C<EV_ASYNC> event on the watcher into the event loop, and instantly
+returns.
-C<ev_feed_event>, this call is safe to do from other threads, signal or
+Unlike C<ev_feed_event>, this call is safe to do from other threads,
-similar contexts (see the discussion of C<EV_ATOMIC_T> in the embedding
+signal or similar contexts (see the discussion of C<EV_ATOMIC_T> in the
-section below on what exactly this means).
+embedding section below on what exactly this means).
 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).
       // now associate this with the loop
       ev_set_userdata (EV_A_ u);
       ev_set_invoke_pending_cb (EV_A_ l_invoke);
       ev_set_loop_release_cb (EV_A_ l_release, l_acquire);
-      // then create the thread running ev_loop
+      // then create the thread running ev_run
       pthread_create (&u->tid, 0, l_run, EV_A);
    }
 The callback for the C<ev_async> watcher does nothing: the watcher is used
 solely to wake up the event loop so it takes notice of any new watchers
 F<event.h> that are not directly supported by the libev core alone.
 In standalone mode, libev will still try to automatically deduce the
 configuration, but has to be more conservative.
+=item EV_USE_FLOOR
+If defined to be C<1>, libev will use the C<floor ()> function for its
+periodic reschedule calculations, otherwise libev will fall back on a
+portable (slower) implementation. If you enable this, you usually have to
+link against libm or something equivalent. Enabling this when the C<floor>
+function is not available will fail, so the safe default is to not enable
+this.
 =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,
 The physical time that is observed. It is apparently strictly monotonic :)
 =item wall-clock time
 The time and date as shown on clocks. Unlike real time, it can actually
-be wrong and jump forwards and backwards, e.g. when the you adjust your
+be wrong and jump forwards and backwards, e.g. when you adjust your
 clock.
 =item watcher
 A data structure that describes interest in certain events. Watchers need
 =back
 =head1 AUTHOR
 Marc Lehmann <libev@schmorp.de>, with repeated corrections by Mikael
-Magnusson and Emanuele Giaquinta.
+Magnusson and Emanuele Giaquinta, and minor corrections by many others.

Diff Legend

-–
+Removed lines
-+
+Added lines
-<
+Changed lines
->
+Changed lines

Comparing libev/ev.pod (file contents): Revision 1.361 by root, Sun Jan 23 18:53:06 2011 UTC vs. Revision 1.367 by root, Sun Feb 20 02:56:23 2011 UTC

Diff Legend

Comparing libev/ev.pod (file contents):
Revision 1.361 by root, Sun Jan 23 18:53:06 2011 UTC vs.
Revision 1.367 by root, Sun Feb 20 02:56:23 2011 UTC