… | |
… | |
572 | Returns the current "event loop time", which is the time the event loop |
572 | Returns the current "event loop time", which is the time the event loop |
573 | received events and started processing them. This timestamp does not |
573 | received events and started processing them. This timestamp does not |
574 | change as long as callbacks are being processed, and this is also the base |
574 | change as long as callbacks are being processed, and this is also the base |
575 | time used for relative timers. You can treat it as the timestamp of the |
575 | time used for relative timers. You can treat it as the timestamp of the |
576 | event occurring (or more correctly, libev finding out about it). |
576 | event occurring (or more correctly, libev finding out about it). |
|
|
577 | |
|
|
578 | =item ev_now_update (loop) |
|
|
579 | |
|
|
580 | Establishes the current time by querying the kernel, updating the time |
|
|
581 | returned by C<ev_now ()> in the progress. This is a costly operation and |
|
|
582 | is usually done automatically within C<ev_loop ()>. |
|
|
583 | |
|
|
584 | This function is rarely useful, but when some event callback runs for a |
|
|
585 | very long time without entering the event loop, updating libev's idea of |
|
|
586 | the current time is a good idea. |
|
|
587 | |
|
|
588 | See also "The special problem of time updates" in the C<ev_timer> section. |
577 | |
589 | |
578 | =item ev_loop (loop, int flags) |
590 | =item ev_loop (loop, int flags) |
579 | |
591 | |
580 | Finally, this is it, the event handler. This function usually is called |
592 | Finally, this is it, the event handler. This function usually is called |
581 | after you initialised all your watchers and you want to start handling |
593 | after you initialised all your watchers and you want to start handling |
… | |
… | |
1134 | C<EVBACKEND_POLL>. |
1146 | C<EVBACKEND_POLL>. |
1135 | |
1147 | |
1136 | =head3 The special problem of SIGPIPE |
1148 | =head3 The special problem of SIGPIPE |
1137 | |
1149 | |
1138 | While not really specific to libev, it is easy to forget about SIGPIPE: |
1150 | While not really specific to libev, it is easy to forget about SIGPIPE: |
1139 | when reading from a pipe whose other end has been closed, your program |
1151 | when writing to a pipe whose other end has been closed, your program gets |
1140 | gets send a SIGPIPE, which, by default, aborts your program. For most |
1152 | send a SIGPIPE, which, by default, aborts your program. For most programs |
1141 | programs this is sensible behaviour, for daemons, this is usually |
1153 | this is sensible behaviour, for daemons, this is usually undesirable. |
1142 | undesirable. |
|
|
1143 | |
1154 | |
1144 | So when you encounter spurious, unexplained daemon exits, make sure you |
1155 | So when you encounter spurious, unexplained daemon exits, make sure you |
1145 | ignore SIGPIPE (and maybe make sure you log the exit status of your daemon |
1156 | ignore SIGPIPE (and maybe make sure you log the exit status of your daemon |
1146 | somewhere, as that would have given you a big clue). |
1157 | somewhere, as that would have given you a big clue). |
1147 | |
1158 | |
… | |
… | |
1198 | times out after an hour and you reset your system clock to January last |
1209 | times out after an hour and you reset your system clock to January last |
1199 | year, it will still time out after (roughly) and hour. "Roughly" because |
1210 | year, it will still time out after (roughly) and hour. "Roughly" because |
1200 | detecting time jumps is hard, and some inaccuracies are unavoidable (the |
1211 | detecting time jumps is hard, and some inaccuracies are unavoidable (the |
1201 | monotonic clock option helps a lot here). |
1212 | monotonic clock option helps a lot here). |
1202 | |
1213 | |
|
|
1214 | The callback is guaranteed to be invoked only after its timeout has passed, |
|
|
1215 | but if multiple timers become ready during the same loop iteration then |
|
|
1216 | order of execution is undefined. |
|
|
1217 | |
|
|
1218 | =head3 The special problem of time updates |
|
|
1219 | |
|
|
1220 | Establishing the current time is a costly operation (it usually takes at |
|
|
1221 | least two system calls): EV therefore updates its idea of the current |
|
|
1222 | time only before and after C<ev_loop> polls for new events, which causes |
|
|
1223 | a growing difference between C<ev_now ()> and C<ev_time ()> when handling |
|
|
1224 | lots of events. |
|
|
1225 | |
1203 | The relative timeouts are calculated relative to the C<ev_now ()> |
1226 | The relative timeouts are calculated relative to the C<ev_now ()> |
1204 | time. This is usually the right thing as this timestamp refers to the time |
1227 | time. This is usually the right thing as this timestamp refers to the time |
1205 | of the event triggering whatever timeout you are modifying/starting. If |
1228 | of the event triggering whatever timeout you are modifying/starting. If |
1206 | you suspect event processing to be delayed and you I<need> to base the timeout |
1229 | you suspect event processing to be delayed and you I<need> to base the |
1207 | on the current time, use something like this to adjust for this: |
1230 | timeout on the current time, use something like this to adjust for this: |
1208 | |
1231 | |
1209 | ev_timer_set (&timer, after + ev_now () - ev_time (), 0.); |
1232 | ev_timer_set (&timer, after + ev_now () - ev_time (), 0.); |
1210 | |
1233 | |
1211 | The callback is guaranteed to be invoked only after its timeout has passed, |
1234 | If the event loop is suspended for a long time, one can also force an |
1212 | but if multiple timers become ready during the same loop iteration then |
1235 | update of the time returned by C<ev_now ()> by calling C<ev_now_update |
1213 | order of execution is undefined. |
1236 | ()>. |
1214 | |
1237 | |
1215 | =head3 Watcher-Specific Functions and Data Members |
1238 | =head3 Watcher-Specific Functions and Data Members |
1216 | |
1239 | |
1217 | =over 4 |
1240 | =over 4 |
1218 | |
1241 | |
… | |
… | |
1569 | handler, you can override it easily by installing your own handler for |
1592 | handler, you can override it easily by installing your own handler for |
1570 | C<SIGCHLD> after initialising the default loop, and making sure the |
1593 | C<SIGCHLD> after initialising the default loop, and making sure the |
1571 | default loop never gets destroyed. You are encouraged, however, to use an |
1594 | default loop never gets destroyed. You are encouraged, however, to use an |
1572 | event-based approach to child reaping and thus use libev's support for |
1595 | event-based approach to child reaping and thus use libev's support for |
1573 | that, so other libev users can use C<ev_child> watchers freely. |
1596 | that, so other libev users can use C<ev_child> watchers freely. |
|
|
1597 | |
|
|
1598 | =head3 Stopping the Child Watcher |
|
|
1599 | |
|
|
1600 | Currently, the child watcher never gets stopped, even when the |
|
|
1601 | child terminates, so normally one needs to stop the watcher in the |
|
|
1602 | callback. Future versions of libev might stop the watcher automatically |
|
|
1603 | when a child exit is detected. |
1574 | |
1604 | |
1575 | =head3 Watcher-Specific Functions and Data Members |
1605 | =head3 Watcher-Specific Functions and Data Members |
1576 | |
1606 | |
1577 | =over 4 |
1607 | =over 4 |
1578 | |
1608 | |
… | |
… | |
2664 | L<http://rev.rubyforge.org/>. |
2694 | L<http://rev.rubyforge.org/>. |
2665 | |
2695 | |
2666 | =item D |
2696 | =item D |
2667 | |
2697 | |
2668 | Leandro Lucarella has written a D language binding (F<ev.d>) for libev, to |
2698 | Leandro Lucarella has written a D language binding (F<ev.d>) for libev, to |
2669 | be found at L<http://git.llucax.com.ar/?p=software/ev.d.git;a=summary>. |
2699 | be found at L<http://proj.llucax.com.ar/wiki/evd>. |
2670 | |
2700 | |
2671 | =back |
2701 | =back |
2672 | |
2702 | |
2673 | |
2703 | |
2674 | =head1 MACRO MAGIC |
2704 | =head1 MACRO MAGIC |