… | |
… | |
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 | |