ViewVC Help
View File | Revision Log | Show Annotations | Download File
/cvs/libev/ev.pod
(Generate patch)

Comparing libev/ev.pod (file contents):
Revision 1.367 by root, Sun Feb 20 02:56:23 2011 UTC vs.
Revision 1.370 by root, Thu Jun 2 23:42:40 2011 UTC

… …
483=item C<EVBACKEND_EPOLL> (value 4, Linux) 483=item C<EVBACKEND_EPOLL> (value 4, Linux)
484 484
485Use the linux-specific epoll(7) interface (for both pre- and post-2.6.9 485Use the linux-specific epoll(7) interface (for both pre- and post-2.6.9
486kernels). 486kernels).
487 487
488For few fds, this backend is a bit little slower than poll and select, 488For few fds, this backend is a bit little slower than poll and select, but
489but it scales phenomenally better. While poll and select usually scale 489it scales phenomenally better. While poll and select usually scale like
490like O(total_fds) where n is the total number of fds (or the highest fd), 490O(total_fds) where total_fds is the total number of fds (or the highest
491epoll scales either O(1) or O(active_fds). 491fd), epoll scales either O(1) or O(active_fds).
492 492
493The epoll mechanism deserves honorable mention as the most misdesigned 493The epoll mechanism deserves honorable mention as the most misdesigned
494of the more advanced event mechanisms: mere annoyances include silently 494of the more advanced event mechanisms: mere annoyances include silently
495dropping file descriptors, requiring a system call per change per file 495dropping file descriptors, requiring a system call per change per file
496descriptor (and unnecessary guessing of parameters), problems with dup, 496descriptor (and unnecessary guessing of parameters), problems with dup,
… …
4990.1ms) and so on. The biggest issue is fork races, however - if a program 4990.1ms) and so on. The biggest issue is fork races, however - if a program
500forks then I<both> parent and child process have to recreate the epoll 500forks then I<both> parent and child process have to recreate the epoll
501set, which can take considerable time (one syscall per file descriptor) 501set, which can take considerable time (one syscall per file descriptor)
502and is of course hard to detect. 502and is of course hard to detect.
503 503
504Epoll is also notoriously buggy - embedding epoll fds I<should> work, but 504Epoll is also notoriously buggy - embedding epoll fds I<should> work,
505of course I<doesn't>, and epoll just loves to report events for totally 505but of course I<doesn't>, and epoll just loves to report events for
506I<different> file descriptors (even already closed ones, so one cannot 506totally I<different> file descriptors (even already closed ones, so
507even remove them from the set) than registered in the set (especially 507one cannot even remove them from the set) than registered in the set
508on SMP systems). Libev tries to counter these spurious notifications by 508(especially on SMP systems). Libev tries to counter these spurious
509employing an additional generation counter and comparing that against the 509notifications by employing an additional generation counter and comparing
510events to filter out spurious ones, recreating the set when required. Last 510that against the events to filter out spurious ones, recreating the set
511when required. Epoll also errornously rounds down timeouts, but gives you
512no way to know when and by how much, so sometimes you have to busy-wait
513because epoll returns immediately despite a nonzero timeout. And last
511not least, it also refuses to work with some file descriptors which work 514not least, it also refuses to work with some file descriptors which work
512perfectly fine with C<select> (files, many character devices...). 515perfectly fine with C<select> (files, many character devices...).
513 516
514Epoll is truly the train wreck analog among event poll mechanisms, 517Epoll is truly the train wreck among event poll mechanisms, a frankenpoll,
515a frankenpoll, cobbled together in a hurry, no thought to design or 518cobbled together in a hurry, no thought to design or interaction with
516interaction with others. 519others. Oh, the pain, will it ever stop...
517 520
518While stopping, setting and starting an I/O watcher in the same iteration 521While stopping, setting and starting an I/O watcher in the same iteration
519will result in some caching, there is still a system call per such 522will result in some caching, there is still a system call per such
520incident (because the same I<file descriptor> could point to a different 523incident (because the same I<file descriptor> could point to a different
521I<file description> now), so its best to avoid that. Also, C<dup ()>'ed 524I<file description> now), so its best to avoid that. Also, C<dup ()>'ed
… …
825This is useful if you are waiting for some external event in conjunction 828This is useful if you are waiting for some external event in conjunction
826with something not expressible using other libev watchers (i.e. "roll your 829with something not expressible using other libev watchers (i.e. "roll your
827own C<ev_run>"). However, a pair of C<ev_prepare>/C<ev_check> watchers is 830own C<ev_run>"). However, a pair of C<ev_prepare>/C<ev_check> watchers is
828usually a better approach for this kind of thing. 831usually a better approach for this kind of thing.
829 832
830Here are the gory details of what C<ev_run> does: 833Here are the gory details of what C<ev_run> does (this is for your
834understanding, not a guarantee that things will work exactly like this in
835future versions):
831 836
832 - Increment loop depth. 837 - Increment loop depth.
833 - Reset the ev_break status. 838 - Reset the ev_break status.
834 - Before the first iteration, call any pending watchers. 839 - Before the first iteration, call any pending watchers.
835 LOOP: 840 LOOP:

Diff Legend

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