| … | |
… | |
| 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 |
| … | |
… | |
| 2708 | event loop blocks next and before C<ev_check> watchers are being called, |
2710 | 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 |
2711 | 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 |
2712 | C<ev_default_fork> cheats and calls it in the wrong process, the fork |
| 2711 | handlers will be invoked, too, of course. |
2713 | handlers will be invoked, too, of course. |
| 2712 | |
2714 | |
|
|
2715 | =head3 The special problem of life after fork - how is it possible? |
|
|
2716 | |
|
|
2717 | Most uses of C<fork()> consist of forking, then some simple calls to ste |
|
|
2718 | up/change the process environment, followed by a call to C<exec()>. This |
|
|
2719 | sequence should be handled by libev without any problems. |
|
|
2720 | |
|
|
2721 | This changes when the application actually wants to do event handling |
|
|
2722 | in the child, or both parent in child, in effect "continuing" after the |
|
|
2723 | fork. |
|
|
2724 | |
|
|
2725 | The default mode of operation (for libev, with application help to detect |
|
|
2726 | forks) is to duplicate all the state in the child, as would be expected |
|
|
2727 | when I<either> the parent I<or> the child process continues. |
|
|
2728 | |
|
|
2729 | When both processes want to continue using libev, then this is usually the |
|
|
2730 | wrong result. In that case, usually one process (typically the parent) is |
|
|
2731 | supposed to continue with all watchers in place as before, while the other |
|
|
2732 | process typically wants to start fresh, i.e. without any active watchers. |
|
|
2733 | |
|
|
2734 | The cleanest and most efficient way to achieve that with libev is to |
|
|
2735 | simply create a new event loop, which of course will be "empty", and |
|
|
2736 | use that for new watchers. This has the advantage of not touching more |
|
|
2737 | memory than necessary, and thus avoiding the copy-on-write, and the |
|
|
2738 | disadvantage of having to use multiple event loops (which do not support |
|
|
2739 | signal watchers). |
|
|
2740 | |
|
|
2741 | When this is not possible, or you want to use the default loop for |
|
|
2742 | other reasons, then in the process that wants to start "fresh", call |
|
|
2743 | C<ev_default_destroy ()> followed by C<ev_default_loop (...)>. Destroying |
|
|
2744 | the default loop will "orphan" (not stop) all registered watchers, so you |
|
|
2745 | have to be careful not to execute code that modifies those watchers. Note |
|
|
2746 | also that in that case, you have to re-register any signal watchers. |
|
|
2747 | |
| 2713 | =head3 Watcher-Specific Functions and Data Members |
2748 | =head3 Watcher-Specific Functions and Data Members |
| 2714 | |
2749 | |
| 2715 | =over 4 |
2750 | =over 4 |
| 2716 | |
2751 | |
| 2717 | =item ev_fork_init (ev_signal *, callback) |
2752 | =item ev_fork_init (ev_signal *, callback) |
