… | |
… | |
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 |
… | |
… | |
3667 | defined to be C<0>, then they are not. |
3671 | defined to be C<0>, then they are not. |
3668 | |
3672 | |
3669 | =item EV_MINIMAL |
3673 | =item EV_MINIMAL |
3670 | |
3674 | |
3671 | If you need to shave off some kilobytes of code at the expense of some |
3675 | If you need to shave off some kilobytes of code at the expense of some |
3672 | speed, define this symbol to C<1>. Currently this is used to override some |
3676 | speed (but with the full API), define this symbol to C<1>. Currently this |
3673 | inlining decisions, saves roughly 30% code size on amd64. It also selects a |
3677 | is used to override some inlining decisions, saves roughly 30% code size |
3674 | much smaller 2-heap for timer management over the default 4-heap. |
3678 | on amd64. It also selects a much smaller 2-heap for timer management over |
|
|
3679 | the default 4-heap. |
|
|
3680 | |
|
|
3681 | You can save even more by disabling watcher types you do not need and |
|
|
3682 | setting C<EV_MAXPRI> == C<EV_MINPRI>. |
3675 | |
3683 | |
3676 | =item EV_PID_HASHSIZE |
3684 | =item EV_PID_HASHSIZE |
3677 | |
3685 | |
3678 | C<ev_child> watchers use a small hash table to distribute workload by |
3686 | C<ev_child> watchers use a small hash table to distribute workload by |
3679 | pid. The default size is C<16> (or C<1> with C<EV_MINIMAL>), usually more |
3687 | pid. The default size is C<16> (or C<1> with C<EV_MINIMAL>), usually more |