From f33a7d9fc29fddfc275c32ac89895119dd0ffeda Mon Sep 17 00:00:00 2001 From: root Date: Tue, 15 Jan 2008 04:07:37 +0000 Subject: [PATCH] *** empty log message *** --- ev.pod | 20 +++++++++----------- 1 file changed, 9 insertions(+), 11 deletions(-) diff --git a/ev.pod b/ev.pod index 6d8fe82..9ef6da2 100644 --- a/ev.pod +++ b/ev.pod @@ -485,14 +485,16 @@ earlier call to C. =item ev_default_fork () -This function reinitialises the kernel state for backends that have -one. Despite the name, you can call it anytime, but it makes most sense -after forking, in either the parent or child process (or both, but that -again makes little sense). +This function sets a flag that causes subsequent C iterations +to reinitialise the kernel state for backends that have one. Despite the +name, you can call it anytime, but it makes most sense after forking, in +the child process (or both child and parent, but that again makes little +sense). You I call it in the child before using any of the libev +functions, and it will only take effect at the next C iteration. -You I call this function in the child process after forking if and -only if you want to use the event library in both processes. If you just -fork+exec, you don't have to call it. +On the other hand, you only need to call this function in the child +process if and only if you want to use the event library in the child. If +you just fork+exec, you don't have to call it at all. The function itself is quite fast and it's usually not a problem to call it just in case after a fork. To make this easy, the function will fit in @@ -500,10 +502,6 @@ quite nicely into a call to C: pthread_atfork (0, 0, ev_default_fork); -At the moment, C and C are safe to use -without calling this function, so if you force one of those backends you -do not need to care. - =item ev_loop_fork (loop) Like C, but acts on an event loop created by -- 2.43.0