--- libev/ev.pod 2007/11/27 20:26:51 1.54 +++ libev/ev.pod 2007/11/29 20:05:59 1.63 @@ -65,12 +65,13 @@ =head1 FEATURES -Libev supports C, C, the Linux-specific C, the +BSD-specific C and the Solaris-specific event port mechanisms +for file descriptor events (C), the Linux C interface +(for C), relative timers (C), absolute timers +with customised rescheduling (C), synchronous signals +(C), process status change events (C), and event +watchers dealing with the event loop mechanism itself (C, C, C and C watchers) as well as file watchers (C) and even limited support for fork events (C). @@ -164,13 +165,14 @@ See the description of C watchers for more info. -=item ev_set_allocator (void *(*cb)(void *ptr, size_t size)) +=item ev_set_allocator (void *(*cb)(void *ptr, long size)) -Sets the allocation function to use (the prototype and semantics are -identical to the realloc C function). It is used to allocate and free -memory (no surprises here). If it returns zero when memory needs to be -allocated, the library might abort or take some potentially destructive -action. The default is your system realloc function. +Sets the allocation function to use (the prototype is similar - the +semantics is identical - to the realloc C function). It is used to +allocate and free memory (no surprises here). If it returns zero when +memory needs to be allocated, the library might abort or take some +potentially destructive action. The default is your system realloc +function. You could override this function in high-availability programs to, say, free some memory if it cannot allocate memory, to use a special allocator, @@ -266,6 +268,26 @@ useful to try out specific backends to test their performance, or to work around bugs. +=item C + +Instead of calling C or C manually after +a fork, you can also make libev check for a fork in each iteration by +enabling this flag. + +This works by calling C on every iteration of the loop, +and thus this might slow down your event loop if you do a lot of loop +iterations and little real work, but is usually not noticable (on my +Linux system for example, C is actually a simple 5-insn sequence +without a syscall and thus I fast, but my Linux system also has +C which is even faster). + +The big advantage of this flag is that you can forget about fork (and +forget about forgetting to tell libev about forking) when you use this +flag. + +This flag setting cannot be overriden or specified in the C +environment variable. + =item C (value 1, portable select backend) This is your standard select(2) backend. Not I standard, as @@ -705,7 +727,7 @@ C is safe) and you must make sure the watcher is available to libev (e.g. you cnanot C it). -=item callback = ev_cb (ev_TYPE *watcher) +=item callback ev_cb (ev_TYPE *watcher) Returns the callback currently set on the watcher. @@ -743,8 +765,37 @@ ... } -More interesting and less C-conformant ways of catsing your callback type -have been omitted.... +More interesting and less C-conformant ways of casting your callback type +instead have been omitted. + +Another common scenario is having some data structure with multiple +watchers: + + struct my_biggy + { + int some_data; + ev_timer t1; + ev_timer t2; + } + +In this case getting the pointer to C is a bit more complicated, +you need to use C: + + #include + + static void + t1_cb (EV_P_ struct ev_timer *w, int revents) + { + struct my_biggy big = (struct my_biggy * + (((char *)w) - offsetof (struct my_biggy, t1)); + } + + static void + t2_cb (EV_P_ struct ev_timer *w, int revents) + { + struct my_biggy big = (struct my_biggy * + (((char *)w) - offsetof (struct my_biggy, t2)); + } =head1 WATCHER TYPES @@ -887,23 +938,25 @@ This will act as if the timer timed out and restart it again if it is repeating. The exact semantics are: -If the timer is started but nonrepeating, stop it. +If the timer is pending, its pending status is cleared. + +If the timer is started but nonrepeating, stop it (as if it timed out). -If the timer is repeating, either start it if necessary (with the repeat -value), or reset the running timer to the repeat value. +If the timer is repeating, either start it if necessary (with the +C value), or reset the running timer to the C value. This sounds a bit complicated, but here is a useful and typical -example: Imagine you have a tcp connection and you want a so-called -idle timeout, that is, you want to be called when there have been, -say, 60 seconds of inactivity on the socket. The easiest way to do -this is to configure an C with C=C=C<60> and calling +example: Imagine you have a tcp connection and you want a so-called idle +timeout, that is, you want to be called when there have been, say, 60 +seconds of inactivity on the socket. The easiest way to do this is to +configure an C with a C value of C<60> and then call C each time you successfully read or write some data. If you go into an idle state where you do not expect data to travel on the -socket, you can stop the timer, and again will automatically restart it if -need be. +socket, you can C the timer, and C will +automatically restart it if need be. -You can also ignore the C value and C altogether -and only ever use the C value: +That means you can ignore the C value and C +altogether and only ever use the C value and C: ev_timer_init (timer, callback, 0., 5.); ev_timer_again (loop, timer); @@ -914,8 +967,8 @@ timer->again = 10.; ev_timer_again (loop, timer); -This is more efficient then stopping/starting the timer eahc time you want -to modify its timeout value. +This is more slightly efficient then stopping/starting the timer each time +you want to modify its timeout value. =item ev_tstamp repeat [read-write] @@ -1194,8 +1247,11 @@ otherwise always forced to be at least one) and all the other fields of the stat buffer having unspecified contents. +The path I be absolute and I end in a slash. If it is +relative and your working directory changes, the behaviour is undefined. + Since there is no standard to do this, the portable implementation simply -calls C regulalry on the path to see if it changed somehow. You +calls C regularly on the path to see if it changed somehow. You can specify a recommended polling interval for this case. If you specify a polling interval of C<0> (highly recommended!) then a I value will be used (which you can expect to be around @@ -1207,8 +1263,13 @@ as even with OS-supported change notifications, this can be resource-intensive. -At the time of this writing, no specific OS backends are implemented, but -if demand increases, at least a kqueue and inotify backend will be added. +At the time of this writing, only the Linux inotify interface is +implemented (implementing kqueue support is left as an exercise for the +reader). Inotify will be used to give hints only and should not change the +semantics of C watchers, which means that libev sometimes needs +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. =over 4 @@ -1789,8 +1850,9 @@ =back -Example: Declare and initialise a check watcher, working regardless of -wether multiple loops are supported or not. +Example: Declare and initialise a check watcher, utilising the above +macros so it will work regardless of wether multiple loops are supported +or not. static void check_cb (EV_P_ ev_timer *w, int revents) @@ -1803,7 +1865,6 @@ ev_check_start (EV_DEFAULT_ &check); ev_loop (EV_DEFAULT_ 0); - =head1 EMBEDDING Libev can (and often is) directly embedded into host @@ -1852,7 +1913,7 @@ ev_win32.c required on win32 platforms only - ev_select.c only when select backend is enabled (which is by default) + ev_select.c only when select backend is enabled (which is enabled by default) ev_poll.c only when poll backend is enabled (disabled by default) ev_epoll.c only when the epoll backend is enabled (disabled by default) ev_kqueue.c only when the kqueue backend is enabled (disabled by default) @@ -1987,6 +2048,12 @@ reserved for future expansion, works like the USE symbols above. +=item EV_USE_INOTIFY + +If defined to be C<1>, libev will compile in support for the Linux inotify +interface to speed up C watchers. Its actual availability will +be detected at runtime. + =item EV_H The name of the F header file used to include it. The default if @@ -2051,7 +2118,15 @@ C watchers use a small hash table to distribute workload by pid. The default size is C<16> (or C<1> with C), usually more than enough. If you need to manage thousands of children you might want to -increase this value. +increase this value (I be a power of two). + +=item EV_INOTIFY_HASHSIZE + +C watchers use a small hash table to distribute workload by +inotify watch id. The default size is C<16> (or C<1> with C), +usually more than enough. If you need to manage thousands of C +watchers you might want to increase this value (I be a power of +two). =item EV_COMMON @@ -2090,12 +2165,17 @@ file. The usage in rxvt-unicode is simpler. It has a F header file -that everybody includes and which overrides some autoconf choices: +that everybody includes and which overrides some configure choices: + #define EV_MINIMAL 1 #define EV_USE_POLL 0 #define EV_MULTIPLICITY 0 - #define EV_PERIODICS 0 + #define EV_PERIODIC_ENABLE 0 + #define EV_STAT_ENABLE 0 + #define EV_FORK_ENABLE 0 #define EV_CONFIG_H + #define EV_MINPRI 0 + #define EV_MAXPRI 0 #include "ev++.h" @@ -2121,7 +2201,7 @@ =item Stopping check/prepare/idle watchers: O(1) -=item Stopping an io/signal/child watcher: O(number_of_watchers_for_this_(fd/signal/pid % 16)) +=item Stopping an io/signal/child watcher: O(number_of_watchers_for_this_(fd/signal/pid % EV_PID_HASHSIZE)) =item Finding the next timer per loop iteration: O(1)