mirror of /home/gitosis/repositories/libev.git
Marc Alexander Lehmann
parent
a0692c62f5
commit
bfcc49b9ef
3
Changes
3
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.
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
||||
|
|
|
|||
58
ev.3
58
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 <ev.h>
|
||||
\&
|
||||
\& #include <stdio.h> // 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
|
||||
|
|
|
|||
Loading…
Reference in New Issue