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

Comparing libev/ev.pod (file contents):
Revision 1.205 by root, Mon Oct 27 12:20:32 2008 UTC vs.
Revision 1.206 by root, Tue Oct 28 12:31:38 2008 UTC

… …
386For few fds, this backend is a bit little slower than poll and select, 386For few fds, this backend is a bit little slower than poll and select,
387but it scales phenomenally better. While poll and select usually scale 387but it scales phenomenally better. While poll and select usually scale
388like O(total_fds) where n is the total number of fds (or the highest fd), 388like O(total_fds) where n is the total number of fds (or the highest fd),
389epoll scales either O(1) or O(active_fds). 389epoll scales either O(1) or O(active_fds).
390 390
391The epoll syscalls are the most misdesigned of the more advanced 391The epoll syscalls are the most misdesigned of the more advanced event
392event mechanisms: probelsm include silently dropping events in some 392mechanisms: problems include silently dropping fds, requiring a system
393hard-to-detect cases, requiring a system call per fd change, no fork 393call per change per fd (and unnecessary guessing of parameters), problems
394support, problems with dup and so on. 394with dup and so on. The biggest issue is fork races, however - if a
395program forks then I<both> parent and child process have to recreate the
396epoll set, which can take considerable time (one syscall per fd) and is of
397course hard to detect.
395 398
396Epoll is also notoriously buggy - embedding epoll fds should work, but 399Epoll is also notoriously buggy - embedding epoll fds should work, but
397of course doesn't, and epoll just loves to report events for totally 400of course doesn't, and epoll just loves to report events for totally
398I<different> file descriptors (even already closed ones, so one cannot 401I<different> file descriptors (even already closed ones, so one cannot
399even remove them from the set) than registered in the set (especially 402even remove them from the set) than registered in the set (especially
… …
409 412
410Best performance from this backend is achieved by not unregistering all 413Best performance from this backend is achieved by not unregistering all
411watchers for a file descriptor until it has been closed, if possible, 414watchers for a file descriptor until it has been closed, if possible,
412i.e. keep at least one watcher active per fd at all times. Stopping and 415i.e. keep at least one watcher active per fd at all times. Stopping and
413starting a watcher (without re-setting it) also usually doesn't cause 416starting a watcher (without re-setting it) also usually doesn't cause
414extra overhead. 417extra overhead. A fork can both result in spurious notifications as well
418as in libev having to destroy and recreate the epoll object, which can
419take considerable time and thus should be avoided.
415 420
416While nominally embeddable in other event loops, this feature is broken in 421While nominally embeddable in other event loops, this feature is broken in
417all kernel versions tested so far. 422all kernel versions tested so far.
418 423
419This backend maps C<EV_READ> and C<EV_WRITE> in the same way as 424This backend maps C<EV_READ> and C<EV_WRITE> in the same way as
… …
434 439
435It scales in the same way as the epoll backend, but the interface to the 440It scales in the same way as the epoll backend, but the interface to the
436kernel is more efficient (which says nothing about its actual speed, of 441kernel is more efficient (which says nothing about its actual speed, of
437course). While stopping, setting and starting an I/O watcher does never 442course). While stopping, setting and starting an I/O watcher does never
438cause an extra system call as with C<EVBACKEND_EPOLL>, it still adds up to 443cause an extra system call as with C<EVBACKEND_EPOLL>, it still adds up to
439two event changes per incident. Support for C<fork ()> is very bad and it 444two event changes per incident. Support for C<fork ()> is very bad (but
440drops fds silently in similarly hard-to-detect cases. 445sane, unlike epoll) and it drops fds silently in similarly hard-to-detect
446cases
441 447
442This backend usually performs well under most conditions. 448This backend usually performs well under most conditions.
443 449
444While nominally embeddable in other event loops, this doesn't work 450While nominally embeddable in other event loops, this doesn't work
445everywhere, so you might need to test for this. And since it is broken 451everywhere, so you might need to test for this. And since it is broken
… …
474might perform better. 480might perform better.
475 481
476On the positive side, with the exception of the spurious readiness 482On the positive side, with the exception of the spurious readiness
477notifications, this backend actually performed fully to specification 483notifications, this backend actually performed fully to specification
478in all tests and is fully embeddable, which is a rare feat among the 484in all tests and is fully embeddable, which is a rare feat among the
479OS-specific backends. 485OS-specific backends (I vastly prefer correctness over speed hacks).
480 486
481This backend maps C<EV_READ> and C<EV_WRITE> in the same way as 487This backend maps C<EV_READ> and C<EV_WRITE> in the same way as
482C<EVBACKEND_POLL>. 488C<EVBACKEND_POLL>.
483 489
484=item C<EVBACKEND_ALL> 490=item C<EVBACKEND_ALL>

Diff Legend

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