[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.216 by root, Thu Nov 13 15:55:38 2008 UTC

 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

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.216 by root, Thu Nov 13 15:55:38 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.216 by root, Thu Nov 13 15:55:38 2008 UTC