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

Comparing libev/ev.pod (file contents):
Revision 1.335 by root, Mon Oct 25 10:32:05 2010 UTC vs.
Revision 1.337 by root, Sun Oct 31 20:20:20 2010 UTC

 epoll scales either O(1) or O(active_fds).
 The epoll mechanism deserves honorable mention as the most misdesigned
 of the more advanced event mechanisms: mere annoyances include silently
 dropping file descriptors, requiring a system call per change per file
-descriptor (and unnecessary guessing of parameters), problems with dup and
+descriptor (and unnecessary guessing of parameters), problems with dup,
+returning before the timeout value requiring additional iterations and so
-so on. The biggest issue is fork races, however - if a program forks then
+on. The biggest issue is fork races, however - if a program forks then
 I<both> parent and child process have to recreate the epoll set, which can
 take considerable time (one syscall per file descriptor) and is of course
 hard to detect.
 Epoll is also notoriously buggy - embedding epoll fds I<should> work, but
 Can be used to make a call to C<ev_run> return early (but only after it
 has processed all outstanding events). The C<how> argument must be either
 C<EVBREAK_ONE>, which will make the innermost C<ev_run> call return, or
 C<EVBREAK_ALL>, which will make all nested C<ev_run> calls return.
-This "unloop state" will be cleared when entering C<ev_run> again.
+This "break state" will be cleared when entering C<ev_run> again.
-It is safe to call C<ev_break> from outside any C<ev_run> calls. ##TODO##
+It is safe to call C<ev_break> from outside any C<ev_run> calls, too.
 =item ev_ref (loop)
 =item ev_unref (loop)

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