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