… | |
… | |
1134 | C<EVBACKEND_POLL>. |
1134 | C<EVBACKEND_POLL>. |
1135 | |
1135 | |
1136 | =head3 The special problem of SIGPIPE |
1136 | =head3 The special problem of SIGPIPE |
1137 | |
1137 | |
1138 | While not really specific to libev, it is easy to forget about SIGPIPE: |
1138 | 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 |
1139 | 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 |
1140 | send a SIGPIPE, which, by default, aborts your program. For most programs |
1141 | programs this is sensible behaviour, for daemons, this is usually |
1141 | this is sensible behaviour, for daemons, this is usually undesirable. |
1142 | undesirable. |
|
|
1143 | |
1142 | |
1144 | So when you encounter spurious, unexplained daemon exits, make sure you |
1143 | 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 |
1144 | 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). |
1145 | somewhere, as that would have given you a big clue). |
1147 | |
1146 | |
… | |
… | |
1198 | times out after an hour and you reset your system clock to January last |
1197 | 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 |
1198 | year, it will still time out after (roughly) and hour. "Roughly" because |
1200 | detecting time jumps is hard, and some inaccuracies are unavoidable (the |
1199 | detecting time jumps is hard, and some inaccuracies are unavoidable (the |
1201 | monotonic clock option helps a lot here). |
1200 | monotonic clock option helps a lot here). |
1202 | |
1201 | |
|
|
1202 | The callback is guaranteed to be invoked only after its timeout has passed, |
|
|
1203 | but if multiple timers become ready during the same loop iteration then |
|
|
1204 | order of execution is undefined. |
|
|
1205 | |
|
|
1206 | =head3 The special problem of time updates |
|
|
1207 | |
|
|
1208 | Requesting the current time is a costly operation (it usually takes at |
|
|
1209 | least two syscalls): EV therefore updates it's idea of the current time |
|
|
1210 | only before and after C<ev_loop> polls for new events, which causes the |
|
|
1211 | difference between C<ev_now ()> and C<ev_time ()>. |
|
|
1212 | |
1203 | The relative timeouts are calculated relative to the C<ev_now ()> |
1213 | 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 |
1214 | 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 |
1215 | 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 |
1216 | 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: |
1217 | timeout on the current time, use something like this to adjust for this: |
1208 | |
1218 | |
1209 | ev_timer_set (&timer, after + ev_now () - ev_time (), 0.); |
1219 | ev_timer_set (&timer, after + ev_now () - ev_time (), 0.); |
1210 | |
|
|
1211 | The callback is guaranteed to be invoked only after its timeout has passed, |
|
|
1212 | but if multiple timers become ready during the same loop iteration then |
|
|
1213 | order of execution is undefined. |
|
|
1214 | |
1220 | |
1215 | =head3 Watcher-Specific Functions and Data Members |
1221 | =head3 Watcher-Specific Functions and Data Members |
1216 | |
1222 | |
1217 | =over 4 |
1223 | =over 4 |
1218 | |
1224 | |
… | |
… | |
1569 | handler, you can override it easily by installing your own handler for |
1575 | handler, you can override it easily by installing your own handler for |
1570 | C<SIGCHLD> after initialising the default loop, and making sure the |
1576 | C<SIGCHLD> after initialising the default loop, and making sure the |
1571 | default loop never gets destroyed. You are encouraged, however, to use an |
1577 | 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 |
1578 | 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. |
1579 | that, so other libev users can use C<ev_child> watchers freely. |
|
|
1580 | |
|
|
1581 | =head3 Stopping the Child Watcher |
|
|
1582 | |
|
|
1583 | Currently, the child watcher never gets stopped, even when the |
|
|
1584 | child terminates, so normally one needs to stop the watcher in the |
|
|
1585 | callback. Future versions of libev might stop the watcher automatically |
|
|
1586 | when a child exit is detected. |
1574 | |
1587 | |
1575 | =head3 Watcher-Specific Functions and Data Members |
1588 | =head3 Watcher-Specific Functions and Data Members |
1576 | |
1589 | |
1577 | =over 4 |
1590 | =over 4 |
1578 | |
1591 | |
… | |
… | |
2664 | L<http://rev.rubyforge.org/>. |
2677 | L<http://rev.rubyforge.org/>. |
2665 | |
2678 | |
2666 | =item D |
2679 | =item D |
2667 | |
2680 | |
2668 | Leandro Lucarella has written a D language binding (F<ev.d>) for libev, to |
2681 | 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>. |
2682 | be found at L<http://proj.llucax.com.ar/wiki/evd>. |
2670 | |
2683 | |
2671 | =back |
2684 | =back |
2672 | |
2685 | |
2673 | |
2686 | |
2674 | =head1 MACRO MAGIC |
2687 | =head1 MACRO MAGIC |