.\" ========================================================================
.\"
.IX Title ""<STANDARD INPUT>" 1"
-.TH "<STANDARD INPUT>" 1 "2007-12-09" "perl v5.8.8" "User Contributed Perl Documentation"
+.TH "<STANDARD INPUT>" 1 "2007-12-12" "perl v5.8.8" "User Contributed Perl Documentation"
.SH "NAME"
libev \- a high performance full\-featured event loop written in C
.SH "SYNOPSIS"
.IP "int ev_version_minor ()" 4
.IX Item "int ev_version_minor ()"
.PD
-You can find out the major and minor version numbers of the library
+You can find out the major and minor \s-1ABI\s0 version numbers of the library
you linked against by calling the functions \f(CW\*(C`ev_version_major\*(C'\fR and
\&\f(CW\*(C`ev_version_minor\*(C'\fR. If you want, you can compare against the global
symbols \f(CW\*(C`EV_VERSION_MAJOR\*(C'\fR and \f(CW\*(C`EV_VERSION_MINOR\*(C'\fR, which specify the
version of the library your program was compiled against.
.Sp
+These version numbers refer to the \s-1ABI\s0 version of the library, not the
+release version.
+.Sp
Usually, it's a good idea to terminate if the major versions mismatch,
-as this indicates an incompatible change. Minor versions are usually
+as this indicates an incompatible change. Minor versions are usually
compatible to older versions, so a larger minor version alone is usually
not a problem.
.Sp
whether a file descriptor is really ready with a known-to-be good interface
such as poll (fortunately in our Xlib example, Xlib already does this on
its own, so its quite safe to use).
+.PP
+\fIThe special problem of disappearing file descriptors\fR
+.IX Subsection "The special problem of disappearing file descriptors"
+.PP
+Some backends (e.g kqueue, epoll) need to be told about closing a file
+descriptor (either by calling \f(CW\*(C`close\*(C'\fR explicitly or by any other means,
+such as \f(CW\*(C`dup\*(C'\fR). The reason is that you register interest in some file
+descriptor, but when it goes away, the operating system will silently drop
+this interest. If another file descriptor with the same number then is
+registered with libev, there is no efficient way to see that this is, in
+fact, a different file descriptor.
+.PP
+To avoid having to explicitly tell libev about such cases, libev follows
+the following policy: Each time \f(CW\*(C`ev_io_set\*(C'\fR is being called, libev
+will assume that this is potentially a new file descriptor, otherwise
+it is assumed that the file descriptor stays the same. That means that
+you \fIhave\fR to call \f(CW\*(C`ev_io_set\*(C'\fR (or \f(CW\*(C`ev_io_init\*(C'\fR) when you change the
+descriptor even if the file descriptor number itself did not change.
+.PP
+This is how one would do it normally anyway, the important point is that
+the libev application should not optimise around libev but should leave
+optimisations to libev.
+.PP
+\fIWatcher-Specific Functions\fR
+.IX Subsection "Watcher-Specific Functions"
.IP "ev_io_init (ev_io *, callback, int fd, int events)" 4
.IX Item "ev_io_init (ev_io *, callback, int fd, int events)"
.PD 0
The callback is guarenteed to be invoked only when its timeout has passed,
but if multiple timers become ready during the same loop iteration then
order of execution is undefined.
+.PP
+\fIWatcher-Specific Functions and Data Members\fR
+.IX Subsection "Watcher-Specific Functions and Data Members"
.IP "ev_timer_init (ev_timer *, callback, ev_tstamp after, ev_tstamp repeat)" 4
.IX Item "ev_timer_init (ev_timer *, callback, ev_tstamp after, ev_tstamp repeat)"
.PD 0
As with timers, the callback is guarenteed to be invoked only when the
time (\f(CW\*(C`at\*(C'\fR) has been passed, but if multiple periodic timers become ready
during the same loop iteration then order of execution is undefined.
+.PP
+\fIWatcher-Specific Functions and Data Members\fR
+.IX Subsection "Watcher-Specific Functions and Data Members"
.IP "ev_periodic_init (ev_periodic *, callback, ev_tstamp at, ev_tstamp interval, reschedule_cb)" 4
.IX Item "ev_periodic_init (ev_periodic *, callback, ev_tstamp at, ev_tstamp interval, reschedule_cb)"
.PD 0
as you don't register any with libev). Similarly, when the last signal
watcher for a signal is stopped libev will reset the signal handler to
\&\s-1SIG_DFL\s0 (regardless of what it was set to before).
+.PP
+\fIWatcher-Specific Functions and Data Members\fR
+.IX Subsection "Watcher-Specific Functions and Data Members"
.IP "ev_signal_init (ev_signal *, callback, int signum)" 4
.IX Item "ev_signal_init (ev_signal *, callback, int signum)"
.PD 0
.IX Subsection "ev_child - watch out for process status changes"
Child watchers trigger when your process receives a \s-1SIGCHLD\s0 in response to
some child status changes (most typically when a child of yours dies).
+.PP
+\fIWatcher-Specific Functions and Data Members\fR
+.IX Subsection "Watcher-Specific Functions and Data Members"
.IP "ev_child_init (ev_child *, callback, int pid)" 4
.IX Item "ev_child_init (ev_child *, callback, int pid)"
.PD 0
to fall back to regular polling again even with inotify, but changes are
usually detected immediately, and if the file exists there will be no
polling.
+.PP
+\fIWatcher-Specific Functions and Data Members\fR
+.IX Subsection "Watcher-Specific Functions and Data Members"
.IP "ev_stat_init (ev_stat *, callback, const char *path, ev_tstamp interval)" 4
.IX Item "ev_stat_init (ev_stat *, callback, const char *path, ev_tstamp interval)"
.PD 0
effect on its own sometimes), idle watchers are a good place to do
\&\*(L"pseudo\-background processing\*(R", or delay processing stuff to after the
event loop has handled all outstanding events.
+.PP
+\fIWatcher-Specific Functions and Data Members\fR
+.IX Subsection "Watcher-Specific Functions and Data Members"
.IP "ev_idle_init (ev_signal *, callback)" 4
.IX Item "ev_idle_init (ev_signal *, callback)"
Initialises and configures the idle watcher \- it has no parameters of any
loops those other event loops might be in an unusable state until their
\&\f(CW\*(C`ev_check\*(C'\fR watcher ran (always remind yourself to coexist peacefully with
others).
+.PP
+\fIWatcher-Specific Functions and Data Members\fR
+.IX Subsection "Watcher-Specific Functions and Data Members"
.IP "ev_prepare_init (ev_prepare *, callback)" 4
.IX Item "ev_prepare_init (ev_prepare *, callback)"
.PD 0
\& else
\& loop_lo = loop_hi;
.Ve
+.PP
+\fIWatcher-Specific Functions and Data Members\fR
+.IX Subsection "Watcher-Specific Functions and Data Members"
.IP "ev_embed_init (ev_embed *, callback, struct ev_loop *embedded_loop)" 4
.IX Item "ev_embed_init (ev_embed *, callback, struct ev_loop *embedded_loop)"
.PD 0
and only in the child after the fork. If whoever good citizen calling
\&\f(CW\*(C`ev_default_fork\*(C'\fR cheats and calls it in the wrong process, the fork
handlers will be invoked, too, of course.
+.PP
+\fIWatcher-Specific Functions and Data Members\fR
+.IX Subsection "Watcher-Specific Functions and Data Members"
.IP "ev_fork_init (ev_signal *, callback)" 4
.IX Item "ev_fork_init (ev_signal *, callback)"
Initialises and configures the fork watcher \- it has no parameters of any
projects / software / libev.git / blobdiff