… | |
… | |
644 | |
644 | |
645 | This function is rarely useful, but when some event callback runs for a |
645 | This function is rarely useful, but when some event callback runs for a |
646 | very long time without entering the event loop, updating libev's idea of |
646 | very long time without entering the event loop, updating libev's idea of |
647 | the current time is a good idea. |
647 | the current time is a good idea. |
648 | |
648 | |
649 | See also "The special problem of time updates" in the C<ev_timer> section. |
649 | See also L<The special problem of time updates> in the C<ev_timer> section. |
650 | |
650 | |
651 | =item ev_suspend (loop) |
651 | =item ev_suspend (loop) |
652 | |
652 | |
653 | =item ev_resume (loop) |
653 | =item ev_resume (loop) |
654 | |
654 | |
… | |
… | |
1332 | descriptors to non-blocking mode is also usually a good idea (but not |
1332 | descriptors to non-blocking mode is also usually a good idea (but not |
1333 | required if you know what you are doing). |
1333 | required if you know what you are doing). |
1334 | |
1334 | |
1335 | If you cannot use non-blocking mode, then force the use of a |
1335 | If you cannot use non-blocking mode, then force the use of a |
1336 | known-to-be-good backend (at the time of this writing, this includes only |
1336 | known-to-be-good backend (at the time of this writing, this includes only |
1337 | C<EVBACKEND_SELECT> and C<EVBACKEND_POLL>). |
1337 | C<EVBACKEND_SELECT> and C<EVBACKEND_POLL>). The same applies to file |
|
|
1338 | descriptors for which non-blocking operation makes no sense (such as |
|
|
1339 | files) - libev doesn't guarentee any specific behaviour in that case. |
1338 | |
1340 | |
1339 | Another thing you have to watch out for is that it is quite easy to |
1341 | Another thing you have to watch out for is that it is quite easy to |
1340 | receive "spurious" readiness notifications, that is your callback might |
1342 | receive "spurious" readiness notifications, that is your callback might |
1341 | be called with C<EV_READ> but a subsequent C<read>(2) will actually block |
1343 | be called with C<EV_READ> but a subsequent C<read>(2) will actually block |
1342 | because there is no data. Not only are some backends known to create a |
1344 | because there is no data. Not only are some backends known to create a |
… | |
… | |
1463 | year, it will still time out after (roughly) one hour. "Roughly" because |
1465 | year, it will still time out after (roughly) one hour. "Roughly" because |
1464 | detecting time jumps is hard, and some inaccuracies are unavoidable (the |
1466 | detecting time jumps is hard, and some inaccuracies are unavoidable (the |
1465 | monotonic clock option helps a lot here). |
1467 | monotonic clock option helps a lot here). |
1466 | |
1468 | |
1467 | The callback is guaranteed to be invoked only I<after> its timeout has |
1469 | The callback is guaranteed to be invoked only I<after> its timeout has |
1468 | passed. If multiple timers become ready during the same loop iteration |
1470 | passed (not I<at>, so on systems with very low-resolution clocks this |
1469 | then the ones with earlier time-out values are invoked before ones with |
1471 | might introduce a small delay). If multiple timers become ready during the |
|
|
1472 | same loop iteration then the ones with earlier time-out values are invoked |
1470 | later time-out values (but this is no longer true when a callback calls |
1473 | before ones with later time-out values (but this is no longer true when a |
1471 | C<ev_loop> recursively). |
1474 | callback calls C<ev_loop> recursively). |
1472 | |
1475 | |
1473 | =head3 Be smart about timeouts |
1476 | =head3 Be smart about timeouts |
1474 | |
1477 | |
1475 | Many real-world problems involve some kind of timeout, usually for error |
1478 | Many real-world problems involve some kind of timeout, usually for error |
1476 | recovery. A typical example is an HTTP request - if the other side hangs, |
1479 | recovery. A typical example is an HTTP request - if the other side hangs, |
… | |
… | |
2708 | event loop blocks next and before C<ev_check> watchers are being called, |
2711 | event loop blocks next and before C<ev_check> watchers are being called, |
2709 | and only in the child after the fork. If whoever good citizen calling |
2712 | and only in the child after the fork. If whoever good citizen calling |
2710 | C<ev_default_fork> cheats and calls it in the wrong process, the fork |
2713 | C<ev_default_fork> cheats and calls it in the wrong process, the fork |
2711 | handlers will be invoked, too, of course. |
2714 | handlers will be invoked, too, of course. |
2712 | |
2715 | |
|
|
2716 | =head3 The special problem of life after fork - how is it possible? |
|
|
2717 | |
|
|
2718 | Most uses of C<fork()> consist of forking, then some simple calls to ste |
|
|
2719 | up/change the process environment, followed by a call to C<exec()>. This |
|
|
2720 | sequence should be handled by libev without any problems. |
|
|
2721 | |
|
|
2722 | This changes when the application actually wants to do event handling |
|
|
2723 | in the child, or both parent in child, in effect "continuing" after the |
|
|
2724 | fork. |
|
|
2725 | |
|
|
2726 | The default mode of operation (for libev, with application help to detect |
|
|
2727 | forks) is to duplicate all the state in the child, as would be expected |
|
|
2728 | when I<either> the parent I<or> the child process continues. |
|
|
2729 | |
|
|
2730 | When both processes want to continue using libev, then this is usually the |
|
|
2731 | wrong result. In that case, usually one process (typically the parent) is |
|
|
2732 | supposed to continue with all watchers in place as before, while the other |
|
|
2733 | process typically wants to start fresh, i.e. without any active watchers. |
|
|
2734 | |
|
|
2735 | The cleanest and most efficient way to achieve that with libev is to |
|
|
2736 | simply create a new event loop, which of course will be "empty", and |
|
|
2737 | use that for new watchers. This has the advantage of not touching more |
|
|
2738 | memory than necessary, and thus avoiding the copy-on-write, and the |
|
|
2739 | disadvantage of having to use multiple event loops (which do not support |
|
|
2740 | signal watchers). |
|
|
2741 | |
|
|
2742 | When this is not possible, or you want to use the default loop for |
|
|
2743 | other reasons, then in the process that wants to start "fresh", call |
|
|
2744 | C<ev_default_destroy ()> followed by C<ev_default_loop (...)>. Destroying |
|
|
2745 | the default loop will "orphan" (not stop) all registered watchers, so you |
|
|
2746 | have to be careful not to execute code that modifies those watchers. Note |
|
|
2747 | also that in that case, you have to re-register any signal watchers. |
|
|
2748 | |
2713 | =head3 Watcher-Specific Functions and Data Members |
2749 | =head3 Watcher-Specific Functions and Data Members |
2714 | |
2750 | |
2715 | =over 4 |
2751 | =over 4 |
2716 | |
2752 | |
2717 | =item ev_fork_init (ev_signal *, callback) |
2753 | =item ev_fork_init (ev_signal *, callback) |