|
|
|
@ -6,7 +6,7 @@
|
|
|
|
|
<meta name="description" content="Pod documentation for libev" />
|
|
|
|
|
<meta name="inputfile" content="<standard input>" />
|
|
|
|
|
<meta name="outputfile" content="<standard output>" />
|
|
|
|
|
<meta name="created" content="Thu Nov 22 13:28:34 2007" />
|
|
|
|
|
<meta name="created" content="Fri Nov 23 05:35:59 2007" />
|
|
|
|
|
<meta name="generator" content="Pod::Xhtml 1.57" />
|
|
|
|
|
<link rel="stylesheet" href="http://res.tst.eu/pod.css"/></head>
|
|
|
|
|
<body>
|
|
|
|
@ -274,9 +274,9 @@ earlier call to <code>ev_loop_new</code>.</p>
|
|
|
|
|
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).</p>
|
|
|
|
|
<p>You <i>must</i> call this function 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.</p>
|
|
|
|
|
<p>You <i>must</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.</p>
|
|
|
|
|
<p>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
|
|
|
|
|
quite nicely into a call to <code>pthread_atfork</code>:</p>
|
|
|
|
|