… | |
… | |
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) |