.\" ========================================================================
.\"
.IX Title ""<STANDARD INPUT>" 1"
-.TH "<STANDARD INPUT>" 1 "2007-12-08" "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
periodic watcher to trigger in 10 seconds (by specifiying e.g. \f(CW\*(C`ev_now ()
+ 10.\*(C'\fR) and then reset your system clock to the last year, then it will
take a year to trigger the event (unlike an \f(CW\*(C`ev_timer\*(C'\fR, which would trigger
-roughly 10 seconds later and of course not if you reset your system time
-again).
+roughly 10 seconds later).
.PP
They can also be used to implement vastly more complex timers, such as
-triggering an event on eahc midnight, local time.
+triggering an event on each midnight, local time or other, complicated,
+rules.
.PP
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
Lots of arguments, lets sort it out... There are basically three modes of
operation, and we will explain them from simplest to complex:
.RS 4
-.IP "* absolute timer (interval = reschedule_cb = 0)" 4
-.IX Item "absolute timer (interval = reschedule_cb = 0)"
+.IP "* absolute timer (at = time, interval = reschedule_cb = 0)" 4
+.IX Item "absolute timer (at = time, interval = reschedule_cb = 0)"
In this configuration the watcher triggers an event at the wallclock time
\&\f(CW\*(C`at\*(C'\fR and doesn't repeat. It will not adjust when a time jump occurs,
that is, if it is to be run at January 1st 2011 then it will run when the
system time reaches or surpasses this time.
-.IP "* non-repeating interval timer (interval > 0, reschedule_cb = 0)" 4
-.IX Item "non-repeating interval timer (interval > 0, reschedule_cb = 0)"
+.IP "* non-repeating interval timer (at = offset, interval > 0, reschedule_cb = 0)" 4
+.IX Item "non-repeating interval timer (at = offset, interval > 0, reschedule_cb = 0)"
In this mode the watcher will always be scheduled to time out at the next
-\&\f(CW\*(C`at + N * interval\*(C'\fR time (for some integer N) and then repeat, regardless
-of any time jumps.
+\&\f(CW\*(C`at + N * interval\*(C'\fR time (for some integer N, which can also be negative)
+and then repeat, regardless of any time jumps.
.Sp
This can be used to create timers that do not drift with respect to system
time:
Another way to think about it (for the mathematically inclined) is that
\&\f(CW\*(C`ev_periodic\*(C'\fR will try to run the callback in this mode at the next possible
time where \f(CW\*(C`time = at (mod interval)\*(C'\fR, regardless of any time jumps.
-.IP "* manual reschedule mode (reschedule_cb = callback)" 4
-.IX Item "manual reschedule mode (reschedule_cb = callback)"
+.Sp
+For numerical stability it is preferable that the \f(CW\*(C`at\*(C'\fR value is near
+\&\f(CW\*(C`ev_now ()\*(C'\fR (the current time), but there is no range requirement for
+this value.
+.IP "* manual reschedule mode (at and interval ignored, reschedule_cb = callback)" 4
+.IX Item "manual reschedule mode (at and interval ignored, reschedule_cb = callback)"
In this mode the values for \f(CW\*(C`interval\*(C'\fR and \f(CW\*(C`at\*(C'\fR are both being
ignored. Instead, each time the periodic watcher gets scheduled, the
reschedule callback will be called with the watcher as first, and the
\&\s-1NOTE:\s0 \fIThis callback \s-1MUST\s0 \s-1NOT\s0 stop or destroy any periodic watcher,
ever, or make any event loop modifications\fR. If you need to stop it,
return \f(CW\*(C`now + 1e30\*(C'\fR (or so, fudge fudge) and stop it afterwards (e.g. by
-starting a prepare watcher).
+starting an \f(CW\*(C`ev_prepare\*(C'\fR watcher, which is legal).
.Sp
Its prototype is \f(CW\*(C`ev_tstamp (*reschedule_cb)(struct ev_periodic *w,
ev_tstamp now)\*(C'\fR, e.g.:
when you changed some parameters or the reschedule callback would return
a different time than the last time it was called (e.g. in a crond like
program when the crontabs have changed).
+.IP "ev_tstamp offset [read\-write]" 4
+.IX Item "ev_tstamp offset [read-write]"
+When repeating, this contains the offset value, otherwise this is the
+absolute point in time (the \f(CW\*(C`at\*(C'\fR value passed to \f(CW\*(C`ev_periodic_set\*(C'\fR).
+.Sp
+Can be modified any time, but changes only take effect when the periodic
+timer fires or \f(CW\*(C`ev_periodic_again\*(C'\fR is being called.
.IP "ev_tstamp interval [read\-write]" 4
.IX Item "ev_tstamp interval [read-write]"
The current interval value. Can be modified any time, but changes only
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