--- libev/ev.pod 2007/12/09 19:47:30 1.80 +++ libev/ev.pod 2007/12/18 01:37:46 1.87 @@ -100,7 +100,9 @@ the beginning of 1970, details are complicated, don't ask). This type is called C, which is what you should use too. It usually aliases to the C type in C, and when you need to do any calculations on -it, you should treat it as such. +it, you should treat it as some floatingpoint value. Unlike the name +component C might indicate, it is also used for time differences +throughout libev. =head1 GLOBAL FUNCTIONS @@ -404,9 +406,18 @@ sense, so e.g. C might still return true. It is your responsibility to either stop all watchers cleanly yoursef I calling this function, or cope with the fact afterwards (which is usually -the easiest thing, youc na just ignore the watchers and/or C them +the easiest thing, you can just ignore the watchers and/or C them for example). +Not that certain global state, such as signal state, will not be freed by +this function, and related watchers (such as signal and child watchers) +would need to be stopped manually. + +In general it is not advisable to call this function except in the +rare occasion where you really need to free e.g. the signal handling +pipe fds. If you need dynamically allocated loops it is better to use +C and C). + =item ev_loop_destroy (loop) Like C, but destroys an event loop created by an @@ -913,6 +924,30 @@ such as poll (fortunately in our Xlib example, Xlib already does this on its own, so its quite safe to use). +=head3 The special problem of disappearing file descriptors + +Some backends (e.g kqueue, epoll) need to be told about closing a file +descriptor (either by calling C explicitly or by any other means, +such as C). 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. + +To avoid having to explicitly tell libev about such cases, libev follows +the following policy: Each time C 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 I to call C (or C) when you change the +descriptor even if the file descriptor number itself did not change. + +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. + + +=head3 Watcher-Specific Functions + =over 4 =item ev_io_init (ev_io *, callback, int fd, int events) @@ -975,6 +1010,8 @@ but if multiple timers become ready during the same loop iteration then order of execution is undefined. +=head3 Watcher-Specific Functions and Data Members + =over 4 =item ev_timer_init (ev_timer *, callback, ev_tstamp after, ev_tstamp repeat) @@ -1089,6 +1126,8 @@ time (C) has been passed, but if multiple periodic timers become ready during the same loop iteration then order of execution is undefined. +=head3 Watcher-Specific Functions and Data Members + =over 4 =item ev_periodic_init (ev_periodic *, callback, ev_tstamp at, ev_tstamp interval, reschedule_cb) @@ -1194,6 +1233,11 @@ switched off. Can be changed any time, but changes only take effect when the periodic timer fires or C is being called. +=item ev_tstamp at [read-only] + +When active, contains the absolute time that the watcher is supposed to +trigger next. + =back Example: Call a callback every hour, or, more precisely, whenever the @@ -1244,6 +1288,8 @@ watcher for a signal is stopped libev will reset the signal handler to SIG_DFL (regardless of what it was set to before). +=head3 Watcher-Specific Functions and Data Members + =over 4 =item ev_signal_init (ev_signal *, callback, int signum) @@ -1265,6 +1311,8 @@ Child watchers trigger when your process receives a SIGCHLD in response to some child status changes (most typically when a child of yours dies). +=head3 Watcher-Specific Functions and Data Members + =over 4 =item ev_child_init (ev_child *, callback, int pid) @@ -1342,6 +1390,8 @@ usually detected immediately, and if the file exists there will be no polling. +=head3 Watcher-Specific Functions and Data Members + =over 4 =item ev_stat_init (ev_stat *, callback, const char *path, ev_tstamp interval) @@ -1433,6 +1483,8 @@ "pseudo-background processing", or delay processing stuff to after the event loop has handled all outstanding events. +=head3 Watcher-Specific Functions and Data Members + =over 4 =item ev_idle_init (ev_signal *, callback) @@ -1509,6 +1561,8 @@ C watcher ran (always remind yourself to coexist peacefully with others). +=head3 Watcher-Specific Functions and Data Members + =over 4 =item ev_prepare_init (ev_prepare *, callback) @@ -1719,6 +1773,8 @@ else loop_lo = loop_hi; +=head3 Watcher-Specific Functions and Data Members + =over 4 =item ev_embed_init (ev_embed *, callback, struct ev_loop *embedded_loop) @@ -1754,6 +1810,8 @@ C cheats and calls it in the wrong process, the fork handlers will be invoked, too, of course. +=head3 Watcher-Specific Functions and Data Members + =over 4 =item ev_fork_init (ev_signal *, callback) @@ -1979,16 +2037,16 @@ Stops the watcher if it is active. Again, no C argument. -=item w->again () C, C only +=item w->again () (C, C only) For C and C, this invokes the corresponding C function. -=item w->sweep () C only +=item w->sweep () (C only) Invokes C. -=item w->update () C only +=item w->update () (C only) Invokes C. @@ -2018,9 +2076,9 @@ =head1 MACRO MAGIC -Libev can be compiled with a variety of options, the most fundemantal is -C. This option determines whether (most) functions and -callbacks have an initial C argument. +Libev can be compiled with a variety of options, the most fundamantal +of which is C. This option determines whether (most) +functions and callbacks have an initial C argument. To make it easier to write programs that cope with either variant, the following macros are defined: