… | |
… | |
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 |
… | |
… | |
994 | { |
1006 | { |
995 | struct ev_io io; |
1007 | struct ev_io io; |
996 | int otherfd; |
1008 | int otherfd; |
997 | void *somedata; |
1009 | void *somedata; |
998 | struct whatever *mostinteresting; |
1010 | struct whatever *mostinteresting; |
999 | } |
1011 | }; |
|
|
1012 | |
|
|
1013 | ... |
|
|
1014 | struct my_io w; |
|
|
1015 | ev_io_init (&w.io, my_cb, fd, EV_READ); |
1000 | |
1016 | |
1001 | And since your callback will be called with a pointer to the watcher, you |
1017 | And since your callback will be called with a pointer to the watcher, you |
1002 | can cast it back to your own type: |
1018 | can cast it back to your own type: |
1003 | |
1019 | |
1004 | static void my_cb (struct ev_loop *loop, struct ev_io *w_, int revents) |
1020 | static void my_cb (struct ev_loop *loop, struct ev_io *w_, int revents) |
… | |
… | |
1008 | } |
1024 | } |
1009 | |
1025 | |
1010 | More interesting and less C-conformant ways of casting your callback type |
1026 | More interesting and less C-conformant ways of casting your callback type |
1011 | instead have been omitted. |
1027 | instead have been omitted. |
1012 | |
1028 | |
1013 | Another common scenario is having some data structure with multiple |
1029 | Another common scenario is to use some data structure with multiple |
1014 | watchers: |
1030 | embedded watchers: |
1015 | |
1031 | |
1016 | struct my_biggy |
1032 | struct my_biggy |
1017 | { |
1033 | { |
1018 | int some_data; |
1034 | int some_data; |
1019 | ev_timer t1; |
1035 | ev_timer t1; |
1020 | ev_timer t2; |
1036 | ev_timer t2; |
1021 | } |
1037 | } |
1022 | |
1038 | |
1023 | In this case getting the pointer to C<my_biggy> is a bit more complicated, |
1039 | In this case getting the pointer to C<my_biggy> is a bit more |
1024 | you need to use C<offsetof>: |
1040 | complicated: Either you store the address of your C<my_biggy> struct |
|
|
1041 | in the C<data> member of the watcher, or you need to use some pointer |
|
|
1042 | arithmetic using C<offsetof> inside your watchers: |
1025 | |
1043 | |
1026 | #include <stddef.h> |
1044 | #include <stddef.h> |
1027 | |
1045 | |
1028 | static void |
1046 | static void |
1029 | t1_cb (EV_P_ struct ev_timer *w, int revents) |
1047 | t1_cb (EV_P_ struct ev_timer *w, int revents) |
… | |
… | |
1134 | C<EVBACKEND_POLL>. |
1152 | C<EVBACKEND_POLL>. |
1135 | |
1153 | |
1136 | =head3 The special problem of SIGPIPE |
1154 | =head3 The special problem of SIGPIPE |
1137 | |
1155 | |
1138 | While not really specific to libev, it is easy to forget about SIGPIPE: |
1156 | 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 |
1157 | 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 |
1158 | send a SIGPIPE, which, by default, aborts your program. For most programs |
1141 | programs this is sensible behaviour, for daemons, this is usually |
1159 | this is sensible behaviour, for daemons, this is usually undesirable. |
1142 | undesirable. |
|
|
1143 | |
1160 | |
1144 | So when you encounter spurious, unexplained daemon exits, make sure you |
1161 | 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 |
1162 | 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). |
1163 | somewhere, as that would have given you a big clue). |
1147 | |
1164 | |
… | |
… | |
1198 | times out after an hour and you reset your system clock to January last |
1215 | 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 |
1216 | year, it will still time out after (roughly) and hour. "Roughly" because |
1200 | detecting time jumps is hard, and some inaccuracies are unavoidable (the |
1217 | detecting time jumps is hard, and some inaccuracies are unavoidable (the |
1201 | monotonic clock option helps a lot here). |
1218 | monotonic clock option helps a lot here). |
1202 | |
1219 | |
|
|
1220 | The callback is guaranteed to be invoked only after its timeout has passed, |
|
|
1221 | but if multiple timers become ready during the same loop iteration then |
|
|
1222 | order of execution is undefined. |
|
|
1223 | |
|
|
1224 | =head3 The special problem of time updates |
|
|
1225 | |
|
|
1226 | Establishing the current time is a costly operation (it usually takes at |
|
|
1227 | least two system calls): EV therefore updates its idea of the current |
|
|
1228 | time only before and after C<ev_loop> polls for new events, which causes |
|
|
1229 | a growing difference between C<ev_now ()> and C<ev_time ()> when handling |
|
|
1230 | lots of events. |
|
|
1231 | |
1203 | The relative timeouts are calculated relative to the C<ev_now ()> |
1232 | 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 |
1233 | 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 |
1234 | 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 |
1235 | 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: |
1236 | timeout on the current time, use something like this to adjust for this: |
1208 | |
1237 | |
1209 | ev_timer_set (&timer, after + ev_now () - ev_time (), 0.); |
1238 | ev_timer_set (&timer, after + ev_now () - ev_time (), 0.); |
1210 | |
1239 | |
1211 | The callback is guaranteed to be invoked only after its timeout has passed, |
1240 | If the event loop is suspended for a long time, you can also force an |
1212 | but if multiple timers become ready during the same loop iteration then |
1241 | update of the time returned by C<ev_now ()> by calling C<ev_now_update |
1213 | order of execution is undefined. |
1242 | ()>. |
1214 | |
1243 | |
1215 | =head3 Watcher-Specific Functions and Data Members |
1244 | =head3 Watcher-Specific Functions and Data Members |
1216 | |
1245 | |
1217 | =over 4 |
1246 | =over 4 |
1218 | |
1247 | |
… | |
… | |
1569 | handler, you can override it easily by installing your own handler for |
1598 | handler, you can override it easily by installing your own handler for |
1570 | C<SIGCHLD> after initialising the default loop, and making sure the |
1599 | C<SIGCHLD> after initialising the default loop, and making sure the |
1571 | default loop never gets destroyed. You are encouraged, however, to use an |
1600 | 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 |
1601 | 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. |
1602 | that, so other libev users can use C<ev_child> watchers freely. |
|
|
1603 | |
|
|
1604 | =head3 Stopping the Child Watcher |
|
|
1605 | |
|
|
1606 | Currently, the child watcher never gets stopped, even when the |
|
|
1607 | child terminates, so normally one needs to stop the watcher in the |
|
|
1608 | callback. Future versions of libev might stop the watcher automatically |
|
|
1609 | when a child exit is detected. |
1574 | |
1610 | |
1575 | =head3 Watcher-Specific Functions and Data Members |
1611 | =head3 Watcher-Specific Functions and Data Members |
1576 | |
1612 | |
1577 | =over 4 |
1613 | =over 4 |
1578 | |
1614 | |