[ViewVC] Diff of: cvs/libev/ev.pod

Comparing libev/ev.pod (file contents):
Revision 1.236 by root, Thu Apr 16 07:56:05 2009 UTC vs.
Revision 1.240 by root, Sat Apr 25 14:12:48 2009 UTC

 name C<loop> (which is always of type C<ev_loop *>) will not have
 this argument.
 =head2 TIME REPRESENTATION
-Libev represents time as a single floating point number, representing the
+Libev represents time as a single floating point number, representing
-(fractional) number of seconds since the (POSIX) epoch (somewhere near
+the (fractional) number of seconds since the (POSIX) epoch (somewhere
-the beginning of 1970, details are complicated, don't ask). This type is
+near the beginning of 1970, details are complicated, don't ask). This
-called C<ev_tstamp>, which is what you should use too. It usually aliases
+type is called C<ev_tstamp>, which is what you should use too. It usually
-to the C<double> type in C, and when you need to do any calculations on
+aliases to the C<double> type in C. When you need to do any calculations
-it, you should treat it as some floating point value. Unlike the name
+on it, you should treat it as some floating point value. Unlike the name
 component C<stamp> might indicate, it is also used for time differences
 throughout libev.
 =head1 ERROR HANDLING
 This function is rarely useful, but when some event callback runs for a
 very long time without entering the event loop, updating libev's idea of
 the current time is a good idea.
-See also "The special problem of time updates" in the C<ev_timer> section.
+See also L<The special problem of time updates> in the C<ev_timer> section.
 =item ev_suspend (loop)
 =item ev_resume (loop)
 descriptors to non-blocking mode is also usually a good idea (but not
 required if you know what you are doing).
 If you cannot use non-blocking mode, then force the use of a
 known-to-be-good backend (at the time of this writing, this includes only
-C<EVBACKEND_SELECT> and C<EVBACKEND_POLL>).
+C<EVBACKEND_SELECT> and C<EVBACKEND_POLL>). The same applies to file
+descriptors for which non-blocking operation makes no sense (such as
+files) - libev doesn't guarentee any specific behaviour in that case.
 Another thing you have to watch out for is that it is quite easy to
 receive "spurious" readiness notifications, that is your callback might
 be called with C<EV_READ> but a subsequent C<read>(2) will actually block
 because there is no data. Not only are some backends known to create a
 year, it will still time out after (roughly) one hour. "Roughly" because
 detecting time jumps is hard, and some inaccuracies are unavoidable (the
 monotonic clock option helps a lot here).
 The callback is guaranteed to be invoked only I<after> its timeout has
-passed. If multiple timers become ready during the same loop iteration
+passed (not I<at>, so on systems with very low-resolution clocks this
-then the ones with earlier time-out values are invoked before ones with
+might introduce a small delay). If multiple timers become ready during the
+same loop iteration then the ones with earlier time-out values are invoked
-later time-out values (but this is no longer true when a callback calls
+before ones with later time-out values (but this is no longer true when a
-C<ev_loop> recursively).
+callback calls C<ev_loop> recursively).
 =head3 Be smart about timeouts
 Many real-world problems involve some kind of timeout, usually for error
 recovery. A typical example is an HTTP request - if the other side hangs,
 event loop blocks next and before C<ev_check> watchers are being called,
 and only in the child after the fork. If whoever good citizen calling
 C<ev_default_fork> cheats and calls it in the wrong process, the fork
 handlers will be invoked, too, of course.
+=head3 The special problem of life after fork - how is it possible?
+Most uses of C<fork()> consist of forking, then some simple calls to ste
+up/change the process environment, followed by a call to C<exec()>. This
+sequence should be handled by libev without any problems.
+This changes when the application actually wants to do event handling
+in the child, or both parent in child, in effect "continuing" after the
+fork.
+The default mode of operation (for libev, with application help to detect
+forks) is to duplicate all the state in the child, as would be expected
+when I<either> the parent I<or> the child process continues.
+When both processes want to continue using libev, then this is usually the
+wrong result. In that case, usually one process (typically the parent) is
+supposed to continue with all watchers in place as before, while the other
+process typically wants to start fresh, i.e. without any active watchers.
+The cleanest and most efficient way to achieve that with libev is to
+simply create a new event loop, which of course will be "empty", and
+use that for new watchers. This has the advantage of not touching more
+memory than necessary, and thus avoiding the copy-on-write, and the
+disadvantage of having to use multiple event loops (which do not support
+signal watchers).
+When this is not possible, or you want to use the default loop for
+other reasons, then in the process that wants to start "fresh", call
+C<ev_default_destroy ()> followed by C<ev_default_loop (...)>. Destroying
+the default loop will "orphan" (not stop) all registered watchers, so you
+have to be careful not to execute code that modifies those watchers. Note
+also that in that case, you have to re-register any signal watchers.
 =head3 Watcher-Specific Functions and Data Members
 =over 4
 =item ev_fork_init (ev_signal *, callback)

Diff Legend

-–
+Removed lines
-+
+Added lines
-<
+Changed lines
->
+Changed lines

Comparing libev/ev.pod (file contents): Revision 1.236 by root, Thu Apr 16 07:56:05 2009 UTC vs. Revision 1.240 by root, Sat Apr 25 14:12:48 2009 UTC

Diff Legend

Comparing libev/ev.pod (file contents):
Revision 1.236 by root, Thu Apr 16 07:56:05 2009 UTC vs.
Revision 1.240 by root, Sat Apr 25 14:12:48 2009 UTC