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

Comparing libev/ev.pod (file contents):
Revision 1.211 by root, Mon Nov 3 14:34:16 2008 UTC vs.
Revision 1.220 by root, Thu Nov 20 11:25:15 2008 UTC

 =head2 EXAMPLE PROGRAM
    // 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;
    ev_timer timeout_watcher;
    int
    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
      ev_io_init (&stdin_watcher, stdin_cb, /*STDIN_FILENO*/ 0, EV_READ);
      ev_io_start (loop, &stdin_watcher);
 i.e. keep at least one watcher active per fd at all times. Stopping and
 starting a watcher (without re-setting it) also usually doesn't cause
 extra overhead. A fork can both result in spurious notifications as well
 as in libev having to destroy and recreate the epoll object, which can
 take considerable time and thus should be avoided.
+All this means that, in practice, C<EVBACKEND_SELECT> can be as fast or
+faster than epoll for maybe up to a hundred file descriptors, depending on
+the usage. So sad.
 While nominally embeddable in other event loops, this feature is broken in
 all kernel versions tested so far.
 This backend maps C<EV_READ> and C<EV_WRITE> in the same way as
      else
        {
          // callback was invoked, but there was some activity, re-arm
          // the watcher to fire in last_activity + 60, which is
          // guaranteed to be in the future, so "again" is positive:
-         w->again = timeout - now;
+         w->repeat = timeout - now;
          ev_timer_again (EV_A_ w);
        }
    }
 To summarise the callback: first calculate the real timeout (defined
 There is no support for kqueue, as apparently it cannot be used to
 implement this functionality, due to the requirement of having a file
 descriptor open on the object at all times, and detecting renames, unlinks
 etc. is difficult.
+=head3 C<stat ()> is a synchronous operation
+Libev doesn't normally do any kind of I/O itself, and so is not blocking
+the process. The exception are C<ev_stat> watchers - those call C<stat
+()>, which is a synchronous operation.
+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
+watcher).
+For networked file systems, calling C<stat ()> can block an indefinite
+time due to network issues, and even under good conditions, a stat call
+often takes multiple milliseconds.
+Therefore, it is best to avoid using C<ev_stat> watchers on networked
+paths, although this is fully supported by libev.
 =head3 The special problem of stat time resolution
 The C<stat ()> system call only supports full-second resolution portably,
 and even on systems where the resolution is higher, most file systems
 Tony Arcieri has written a ruby extension that offers access to a subset
 of the libev API and adds file handle abstractions, asynchronous DNS and
 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 D
 Leandro Lucarella has written a D language binding (F<ev.d>) for libev, to
 be found at L<http://proj.llucax.com.ar/wiki/evd>.
 keeps libev from including F<config.h>, and it also defines dummy
 implementations for some libevent functions (such as logging, which is not
 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
+monotonic clock option at both compile time and runtime. Otherwise no
-of the monotonic clock option will be attempted. If you enable this, you
+use of the monotonic clock option will be attempted. If you enable this,
-usually have to link against librt or something similar. Enabling it when
+you usually have to link against librt or something similar. Enabling it
-the functionality isn't available is safe, though, although you have
+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.
+=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
 If defined to be C<1>, libev will assume that C<nanosleep ()> is available
 and will use it for delays. Otherwise it will use C<select ()>.
 =item EV_SELECT_USE_FD_SET
 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
+C<NFDBITS> or C<fd_mask> definition or it mis-guesses the bitset layout
-exotic systems. This usually limits the range of file descriptors to some
+on exotic systems. This usually limits the range of file descriptors to
-low limit such as 1024 or might have other limitations (winsocket only
+some low limit such as 1024 or might have other limitations (winsocket
-allows 64 sockets). The C<FD_SETSIZE> macro, set before compilation, might
+only allows 64 sockets). The C<FD_SETSIZE> macro, set before compilation,
-influence the size of the C<fd_set> used.
+configures the maximum size of the C<fd_set>.
 =item EV_SELECT_IS_WINSOCKET
 When defined to C<1>, the select backend will assume that
 select/socket/connect etc. don't understand file descriptors but

Diff Legend

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

Comparing libev/ev.pod (file contents): Revision 1.211 by root, Mon Nov 3 14:34:16 2008 UTC vs. Revision 1.220 by root, Thu Nov 20 11:25:15 2008 UTC

Diff Legend

Comparing libev/ev.pod (file contents):
Revision 1.211 by root, Mon Nov 3 14:34:16 2008 UTC vs.
Revision 1.220 by root, Thu Nov 20 11:25:15 2008 UTC