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

Comparing libev/ev.pod (file contents):
Revision 1.360 by root, Mon Jan 17 12:11:12 2011 UTC vs.
Revision 1.374 by sf-exg, Sat Jun 4 16:54:59 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
 you actually want to know. Also interesting is the combination of
 C<ev_update_now> and C<ev_now>.
 =item ev_sleep (ev_tstamp interval)
-Sleep for the given interval: The current thread will be blocked until
+Sleep for the given interval: The current thread will be blocked
-either it is interrupted or the given time interval has passed. Basically
+until either it is interrupted or the given time interval has
+passed (approximately - it might return a bit earlier even if not
+interrupted). Returns immediately if C<< interval <= 0 >>.
-this is a sub-second-resolution C<sleep ()>.
+Basically this is a sub-second-resolution C<sleep ()>.
+The range of the C<interval> is limited - libev only guarantees to work
+with sleep times of up to one day (C<< interval <= 86400 >>).
 =item int ev_version_major ()
 =item int ev_version_minor ()
 example) that can't properly initialise their signal masks.
 =item C<EVFLAG_NOSIGMASK>
 When this flag is specified, then libev will avoid to modify the signal
-mask. Specifically, this means you ahve to make sure signals are unblocked
+mask. Specifically, this means you have to make sure signals are unblocked
 when you want to receive them.
 This behaviour is useful when you want to do your own signal handling, or
 want to handle signals only in specific threads and want to avoid libev
 unblocking the signals.
 =item C<EVBACKEND_EPOLL>   (value 4, Linux)
 Use the linux-specific epoll(7) interface (for both pre- and post-2.6.9
 kernels).
-For few fds, this backend is a bit little slower than poll and select,
+For few fds, this backend is a bit little slower than poll and select, but
-but it scales phenomenally better. While poll and select usually scale
+it scales phenomenally better. While poll and select usually scale like
-like O(total_fds) where n is the total number of fds (or the highest fd),
+O(total_fds) where total_fds is the total number of fds (or the highest
-epoll scales either O(1) or O(active_fds).
+fd), epoll scales either O(1) or O(active_fds).
 The epoll mechanism deserves honorable mention as the most misdesigned
 of the more advanced event mechanisms: mere annoyances include silently
 dropping file descriptors, requiring a system call per change per file
 descriptor (and unnecessary guessing of parameters), problems with dup,
 0.1ms) and so on. The biggest issue is fork races, however - if a program
 forks then I<both> parent and child process have to recreate the epoll
 set, which can take considerable time (one syscall per file descriptor)
 and is of course hard to detect.
-Epoll is also notoriously buggy - embedding epoll fds I<should> work, but
+Epoll is also notoriously buggy - embedding epoll fds I<should> work,
-of course I<doesn't>, and epoll just loves to report events for totally
+but of course I<doesn't>, and epoll just loves to report events for
-I<different> file descriptors (even already closed ones, so one cannot
+totally I<different> file descriptors (even already closed ones, so
-even remove them from the set) than registered in the set (especially
+one cannot even remove them from the set) than registered in the set
-on SMP systems). Libev tries to counter these spurious notifications by
+(especially on SMP systems). Libev tries to counter these spurious
-employing an additional generation counter and comparing that against the
+notifications by employing an additional generation counter and comparing
-events to filter out spurious ones, recreating the set when required. Last
+that against the events to filter out spurious ones, recreating the set
+when required. Epoll also erroneously rounds down timeouts, but gives you
+no way to know when and by how much, so sometimes you have to busy-wait
+because epoll returns immediately despite a nonzero timeout. And last
 not least, it also refuses to work with some file descriptors which work
 perfectly fine with C<select> (files, many character devices...).
-Epoll is truly the train wreck analog among event poll mechanisms,
+Epoll is truly the train wreck among event poll mechanisms, a frankenpoll,
-a frankenpoll, cobbled together in a hurry, no thought to design or
+cobbled together in a hurry, no thought to design or interaction with
-interaction with others.
+others. Oh, the pain, will it ever stop...
 While stopping, setting and starting an I/O watcher in the same iteration
 will result in some caching, there is still a system call per such
 incident (because the same I<file descriptor> could point to a different
 I<file description> now), so its best to avoid that. Also, C<dup ()>'ed
 This is useful if you are waiting for some external event in conjunction
 with something not expressible using other libev watchers (i.e. "roll your
 own C<ev_run>"). However, a pair of C<ev_prepare>/C<ev_check> watchers is
 usually a better approach for this kind of thing.
-Here are the gory details of what C<ev_run> does:
+Here are the gory details of what C<ev_run> does (this is for your
+understanding, not a guarantee that things will work exactly like this in
+future versions):
    - Increment loop depth.
    - Reset the ev_break status.
    - Before the first iteration, call any pending watchers.
    LOOP:
 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
 overhead for the actual polling but can deliver many events at once.
 By setting a higher I<io collect interval> you allow libev to spend more
 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
+C<ev_timer>) will not be affected. Setting this to a non-null value will
 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.
+once per this interval, on average (as long as the host time resolution is
+good enough).
 Likewise, by setting a higher I<timeout collect interval> you allow libev
 to spend more time collecting timeouts, at the expense of increased
 latency/jitter/inexactness (the watcher callback will be called
 later). C<ev_io> watchers will not be affected. Setting this to a non-null
 =over 4
 =item initialiased
-Before a watcher can be registered with the event looop it has to be
+Before a watcher can be registered with the event loop it has to be
 initialised. This can be done with a call to C<ev_TYPE_init>, or calls to
 C<ev_init> followed by the watcher-specific C<ev_TYPE_set> function.
-In this state it is simply some block of memory that is suitable for use
+In this state it is simply some block of memory that is suitable for
-in an event loop. It can be moved around, freed, reused etc. at will.
+use in an event loop. It can be moved around, freed, reused etc. at
+will - as long as you either keep the memory contents intact, or call
+C<ev_TYPE_init> again.
 =item started/running/active
 Once a watcher has been started with a call to C<ev_TYPE_start> it becomes
 property of the event loop, and is actively waiting for events. While in
 latter will clear any pending state the watcher might be in, regardless
 of whether it was active or not, so stopping a watcher explicitly before
 freeing it is often a good idea.
 While stopped (and not pending) the watcher is essentially in the
-initialised state, that is it can be reused, moved, modified in any way
+initialised state, that is, it can be reused, moved, modified in any way
-you wish.
+you wish (but when you trash the memory block, you need to C<ev_TYPE_init>
+it again).
 =back
 =head2 WATCHER PRIORITY MODELS
 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,
 requires, and its I/O model is fundamentally incompatible with the POSIX
 model. Libev still offers limited functionality on this platform in
 the form of the C<EVBACKEND_SELECT> backend, and only supports socket
 descriptors. This only applies when using Win32 natively, not when using
 e.g. cygwin. Actually, it only applies to the microsofts own compilers,
-as every compielr comes with a slightly differently broken/incompatible
+as every compiler comes with a slightly differently broken/incompatible
 environment.
 Lifting these limitations would basically require the full
 re-implementation of the I/O system. If you are into this kind of thing,
 then note that glib does exactly that for you in a very portable way (note
 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.360 by root, Mon Jan 17 12:11:12 2011 UTC vs. Revision 1.374 by sf-exg, Sat Jun 4 16:54:59 2011 UTC

Diff Legend

Comparing libev/ev.pod (file contents):
Revision 1.360 by root, Mon Jan 17 12:11:12 2011 UTC vs.
Revision 1.374 by sf-exg, Sat Jun 4 16:54:59 2011 UTC