… | |
… | |
1492 | |
1492 | |
1493 | The callback is guaranteed to be invoked only I<after> its timeout has |
1493 | The callback is guaranteed to be invoked only I<after> its timeout has |
1494 | passed (not I<at>, so on systems with very low-resolution clocks this |
1494 | passed (not I<at>, so on systems with very low-resolution clocks this |
1495 | might introduce a small delay). If multiple timers become ready during the |
1495 | might introduce a small delay). If multiple timers become ready during the |
1496 | same loop iteration then the ones with earlier time-out values are invoked |
1496 | same loop iteration then the ones with earlier time-out values are invoked |
1497 | before ones with later time-out values (but this is no longer true when a |
1497 | before ones of the same priority with later time-out values (but this is |
1498 | callback calls C<ev_loop> recursively). |
1498 | no longer true when a callback calls C<ev_loop> recursively). |
1499 | |
1499 | |
1500 | =head3 Be smart about timeouts |
1500 | =head3 Be smart about timeouts |
1501 | |
1501 | |
1502 | Many real-world problems involve some kind of timeout, usually for error |
1502 | Many real-world problems involve some kind of timeout, usually for error |
1503 | recovery. A typical example is an HTTP request - if the other side hangs, |
1503 | recovery. A typical example is an HTTP request - if the other side hangs, |
… | |
… | |
2031 | but forking and registering a watcher a few event loop iterations later or |
2031 | but forking and registering a watcher a few event loop iterations later or |
2032 | in the next callback invocation is not. |
2032 | in the next callback invocation is not. |
2033 | |
2033 | |
2034 | Only the default event loop is capable of handling signals, and therefore |
2034 | Only the default event loop is capable of handling signals, and therefore |
2035 | you can only register child watchers in the default event loop. |
2035 | you can only register child watchers in the default event loop. |
|
|
2036 | |
|
|
2037 | Due to some design glitches inside libev, child watchers will always be |
|
|
2038 | handled at maximum priority (their priority is set to C<EV_MAXPRI> by |
|
|
2039 | libev) |
2036 | |
2040 | |
2037 | =head3 Process Interaction |
2041 | =head3 Process Interaction |
2038 | |
2042 | |
2039 | Libev grabs C<SIGCHLD> as soon as the default event loop is |
2043 | Libev grabs C<SIGCHLD> as soon as the default event loop is |
2040 | initialised. This is necessary to guarantee proper behaviour even if |
2044 | initialised. This is necessary to guarantee proper behaviour even if |