From 8c20a0f278301939ecda51c88fa835ea41a0c220 Mon Sep 17 00:00:00 2001 From: root Date: Wed, 19 Nov 2008 10:33:32 +0000 Subject: 3.49 --- Changes | 3 +-- configure.ac | 2 +- ev.3 | 58 +++++++++++++++++++++++++++++++++++++++++++--------------- 3 files changed, 45 insertions(+), 18 deletions(-) diff --git a/Changes b/Changes index 5ae57b5..647c1d6 100644 --- a/Changes +++ b/Changes @@ -1,7 +1,6 @@ Revision history for libev, a high-performance and full-featured event loop. -WISH? monotonic clocks times/GetTickCount for coarse corrections? - +3.49 Wed Nov 19 11:26:53 CET 2008 - ev_stat watchers will now use inotify as a mere hint on kernels <2.6.25, or if the filesystem is not in the "known to be good" list. diff --git a/configure.ac b/configure.ac index b294237..0105bfc 100644 --- a/configure.ac +++ b/configure.ac @@ -1,7 +1,7 @@ AC_INIT AC_CONFIG_SRCDIR([ev_epoll.c]) -AM_INIT_AUTOMAKE(libev,3.48) +AM_INIT_AUTOMAKE(libev,3.49) AC_CONFIG_HEADERS([config.h]) AM_MAINTAINER_MODE diff --git a/ev.3 b/ev.3 index b08bcc2..b20363f 100644 --- a/ev.3 +++ b/ev.3 @@ -132,7 +132,7 @@ .\" ======================================================================== .\" .IX Title "LIBEV 3" -.TH LIBEV 3 "2008-10-30" "libev-3.48" "libev - high performance full featured event loop" +.TH LIBEV 3 "2008-11-17" "libev-3.49" "libev - high performance full featured event loop" .\" For nroff, turn off justification. Always turn off hyphenation; it makes .\" way too many mistakes in technical documents. .if n .ad l @@ -150,6 +150,8 @@ libev \- a high performance full\-featured event loop written in C \& // a single header file is required \& #include \& +\& #include // for puts +\& \& // every watcher type has its own typedef\*(Aqd struct \& // with the name ev_TYPE \& ev_io stdin_watcher; @@ -546,6 +548,10 @@ 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. .Sp +All this means that, in practice, \f(CW\*(C`EVBACKEND_SELECT\*(C'\fR can be as fast or +faster than epoll for maybe up to a hundred file descriptors, depending on +the usage. So sad. +.Sp While nominally embeddable in other event loops, this feature is broken in all kernel versions tested so far. .Sp @@ -1559,7 +1565,7 @@ within the callback: \& // 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); \& } \& } @@ -2083,10 +2089,11 @@ and sees if it changed compared to the last time, invoking the callback if it did. .PP The path does not need to exist: changing from \*(L"path exists\*(R" to \*(L"path does -not exist\*(R" is a status change like any other. The condition \*(L"path does -not exist\*(R" is signified by the \f(CW\*(C`st_nlink\*(C'\fR field being zero (which is -otherwise always forced to be at least one) and all the other fields of -the stat buffer having unspecified contents. +not exist\*(R" is a status change like any other. The condition \*(L"path does not +exist\*(R" (or more correctly \*(L"path cannot be stat'ed\*(R") is signified by the +\&\f(CW\*(C`st_nlink\*(C'\fR field being zero (which is otherwise always forced to be at +least one) and all the other fields of the stat buffer having unspecified +contents. .PP The path \fImust not\fR end in a slash or contain special components such as \&\f(CW\*(C`.\*(C'\fR or \f(CW\*(C`..\*(C'\fR. The path \fIshould\fR be absolute: If it is relative and @@ -2106,9 +2113,9 @@ as even with OS-supported change notifications, this can be resource-intensive. .PP At the time of this writing, the only OS-specific interface implemented -is the Linux inotify interface (implementing kqueue support is left as -an exercise for the reader. Note, however, that the author sees no way -of implementing \f(CW\*(C`ev_stat\*(C'\fR semantics with kqueue). +is the Linux inotify interface (implementing kqueue support is left as an +exercise for the reader. Note, however, that the author sees no way of +implementing \f(CW\*(C`ev_stat\*(C'\fR semantics with kqueue, except as a hint). .PP \fI\s-1ABI\s0 Issues (Largefile Support)\fR .IX Subsection "ABI Issues (Largefile Support)" @@ -2131,23 +2138,44 @@ default compilation environment. \fIInotify and Kqueue\fR .IX Subsection "Inotify and Kqueue" .PP -When \f(CW\*(C`inotify (7)\*(C'\fR support has been compiled into libev (generally -only available with Linux 2.6.25 or above due to bugs in earlier -implementations) and present at runtime, it will be used to speed up -change detection where possible. The inotify descriptor will be created -lazily when the first \f(CW\*(C`ev_stat\*(C'\fR watcher is being started. +When \f(CW\*(C`inotify (7)\*(C'\fR support has been compiled into libev and present at +runtime, it will be used to speed up change detection where possible. The +inotify descriptor will be created lazily when the first \f(CW\*(C`ev_stat\*(C'\fR +watcher is being started. .PP Inotify presence does not change the semantics of \f(CW\*(C`ev_stat\*(C'\fR watchers except that changes might be detected earlier, and in some cases, to avoid making regular \f(CW\*(C`stat\*(C'\fR calls. Even in the presence of inotify support there are many cases where libev has to resort to regular \f(CW\*(C`stat\*(C'\fR polling, -but as long as the path exists, libev usually gets away without polling. +but as long as kernel 2.6.25 or newer is used (2.6.24 and older have too +many bugs), the path exists (i.e. stat succeeds), and the path resides on +a local filesystem (libev currently assumes only ext2/3, jfs, reiserfs and +xfs are fully working) libev usually gets away without polling. .PP 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. .PP +\fI\f(CI\*(C`stat ()\*(C'\fI is a synchronous operation\fR +.IX Subsection "stat () is a synchronous operation" +.PP +Libev doesn't normally do any kind of I/O itself, and so is not blocking +the process. The exception are \f(CW\*(C`ev_stat\*(C'\fR watchers \- those call \f(CW\*(C`stat +()\*(C'\fR, which is a synchronous operation. +.PP +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). +.PP +For networked file systems, calling \f(CW\*(C`stat ()\*(C'\fR can block an indefinite +time due to network issues, and even under good conditions, a stat call +often takes multiple milliseconds. +.PP +Therefore, it is best to avoid using \f(CW\*(C`ev_stat\*(C'\fR watchers on networked +paths, although this is fully supported by libev. +.PP \fIThe special problem of stat time resolution\fR .IX Subsection "The special problem of stat time resolution" .PP -- cgit v1.2.3