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

Comparing libev/ev.pod (file contents):
Revision 1.204 by root, Mon Oct 27 11:08:29 2008 UTC vs.
Revision 1.206 by root, Tue Oct 28 12:31:38 2008 UTC

… …
384=item C<EVBACKEND_EPOLL> (value 4, Linux) 384=item C<EVBACKEND_EPOLL> (value 4, Linux)
385 385
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). The epoll design has a number 389epoll scales either O(1) or O(active_fds).
390of shortcomings, such as silently dropping events in some hard-to-detect 390
391cases and requiring a system call per fd change, no fork support and bad 391The epoll syscalls are the most misdesigned of the more advanced event
392support for dup. 392mechanisms: problems include silently dropping fds, requiring a system
393call per change per fd (and unnecessary guessing of parameters), problems
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.
393 398
394Epoll is also notoriously buggy - embedding epoll fds should work, but 399Epoll is also notoriously buggy - embedding epoll fds should work, but
395of 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
396I<different> file descriptors (even already closed ones) than registered 401I<different> file descriptors (even already closed ones, so one cannot
397in the set (especially on SMP systems). Libev tries to counter these 402even remove them from the set) than registered in the set (especially
398spurious notifications by employing an additional generation counter and 403on SMP systems). Libev tries to counter these spurious notifications by
399comparing that against the events to filter out spurious ones. 404employing an additional generation counter and comparing that against the
405events to filter out spurious ones.
400 406
401While stopping, setting and starting an I/O watcher in the same iteration 407While stopping, setting and starting an I/O watcher in the same iteration
402will result in some caching, there is still a system call per such incident 408will result in some caching, there is still a system call per such incident
403(because the fd could point to a different file description now), so its 409(because the fd could point to a different file description now), so its
404best to avoid that. Also, C<dup ()>'ed file descriptors might not work 410best to avoid that. Also, C<dup ()>'ed file descriptors might not work
… …
406 412
407Best performance from this backend is achieved by not unregistering all 413Best performance from this backend is achieved by not unregistering all
408watchers for a file descriptor until it has been closed, if possible, 414watchers for a file descriptor until it has been closed, if possible,
409i.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
410starting a watcher (without re-setting it) also usually doesn't cause 416starting a watcher (without re-setting it) also usually doesn't cause
411extra 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.
412 420
413While nominally embeddable in other event loops, this feature is broken in 421While nominally embeddable in other event loops, this feature is broken in
414all kernel versions tested so far. 422all kernel versions tested so far.
415 423
416This 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
… …
431 439
432It 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
433kernel is more efficient (which says nothing about its actual speed, of 441kernel is more efficient (which says nothing about its actual speed, of
434course). While stopping, setting and starting an I/O watcher does never 442course). While stopping, setting and starting an I/O watcher does never
435cause 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
436two 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
437drops fds silently in similarly hard-to-detect cases. 445sane, unlike epoll) and it drops fds silently in similarly hard-to-detect
446cases
438 447
439This backend usually performs well under most conditions. 448This backend usually performs well under most conditions.
440 449
441While nominally embeddable in other event loops, this doesn't work 450While nominally embeddable in other event loops, this doesn't work
442everywhere, 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
… …
471might perform better. 480might perform better.
472 481
473On the positive side, with the exception of the spurious readiness 482On the positive side, with the exception of the spurious readiness
474notifications, this backend actually performed fully to specification 483notifications, this backend actually performed fully to specification
475in 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
476OS-specific backends. 485OS-specific backends (I vastly prefer correctness over speed hacks).
477 486
478This 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
479C<EVBACKEND_POLL>. 488C<EVBACKEND_POLL>.
480 489
481=item C<EVBACKEND_ALL> 490=item C<EVBACKEND_ALL>

Diff Legend

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