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

Comparing libev/ev.pod (file contents):
Revision 1.209 by root, Wed Oct 29 14:12:34 2008 UTC vs.
Revision 1.210 by root, Thu Oct 30 08:09:30 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 event 391The epoll mechanism deserves honorable mention as the most misdesigned
392mechanisms: problems include silently dropping fds, requiring a system 392of the more advanced event mechanisms: mere annoyances include silently
393call per change per fd (and unnecessary guessing of parameters), problems 393dropping file descriptors, requiring a system call per change per file
394descriptor (and unnecessary guessing of parameters), problems with dup and
394with dup and so on. The biggest issue is fork races, however - if a 395so on. The biggest issue is fork races, however - if a program forks then
395program forks then I<both> parent and child process have to recreate the 396I<both> parent and child process have to recreate the epoll set, which can
396epoll set, which can take considerable time (one syscall per fd) and is of 397take considerable time (one syscall per file descriptor) and is of course
397course hard to detect. 398hard to detect.
398 399
399Epoll is also notoriously buggy - embedding epoll fds should work, but 400Epoll is also notoriously buggy - embedding epoll fds I<should> work, but
400of course doesn't, and epoll just loves to report events for totally 401of course I<doesn't>, and epoll just loves to report events for totally
401I<different> file descriptors (even already closed ones, so one cannot 402I<different> file descriptors (even already closed ones, so one cannot
402even remove them from the set) than registered in the set (especially 403even remove them from the set) than registered in the set (especially
403on SMP systems). Libev tries to counter these spurious notifications by 404on SMP systems). Libev tries to counter these spurious notifications by
404employing an additional generation counter and comparing that against the 405employing an additional generation counter and comparing that against the
405events to filter out spurious ones. 406events to filter out spurious ones, recreating the set when required.
406 407
407While stopping, setting and starting an I/O watcher in the same iteration 408While stopping, setting and starting an I/O watcher in the same iteration
408will result in some caching, there is still a system call per such incident 409will result in some caching, there is still a system call per such
409(because the fd could point to a different file description now), so its 410incident (because the same I<file descriptor> could point to a different
410best to avoid that. Also, C<dup ()>'ed file descriptors might not work 411I<file description> now), so its best to avoid that. Also, C<dup ()>'ed
411very well if you register events for both fds. 412file descriptors might not work very well if you register events for both
413file descriptors.
412 414
413Best performance from this backend is achieved by not unregistering all 415Best performance from this backend is achieved by not unregistering all
414watchers for a file descriptor until it has been closed, if possible, 416watchers for a file descriptor until it has been closed, if possible,
415i.e. keep at least one watcher active per fd at all times. Stopping and 417i.e. keep at least one watcher active per fd at all times. Stopping and
416starting a watcher (without re-setting it) also usually doesn't cause 418starting a watcher (without re-setting it) also usually doesn't cause
… …
424This backend maps C<EV_READ> and C<EV_WRITE> in the same way as 426This backend maps C<EV_READ> and C<EV_WRITE> in the same way as
425C<EVBACKEND_POLL>. 427C<EVBACKEND_POLL>.
426 428
427=item C<EVBACKEND_KQUEUE> (value 8, most BSD clones) 429=item C<EVBACKEND_KQUEUE> (value 8, most BSD clones)
428 430
429Kqueue deserves special mention, as at the time of this writing, it was 431Kqueue deserves special mention, as at the time of this writing, it
430broken on all BSDs except NetBSD (usually it doesn't work reliably with 432was broken on all BSDs except NetBSD (usually it doesn't work reliably
431anything but sockets and pipes, except on Darwin, where of course it's 433with anything but sockets and pipes, except on Darwin, where of course
432completely useless). For this reason it's not being "auto-detected" unless 434it's completely useless). Unlike epoll, however, whose brokenness
433you explicitly specify it in the flags (i.e. using C<EVBACKEND_KQUEUE>) or 435is by design, these kqueue bugs can (and eventually will) be fixed
434libev was compiled on a known-to-be-good (-enough) system like NetBSD. 436without API changes to existing programs. For this reason it's not being
437"auto-detected" unless you explicitly specify it in the flags (i.e. using
438C<EVBACKEND_KQUEUE>) or libev was compiled on a known-to-be-good (-enough)
439system like NetBSD.
435 440
436You still can embed kqueue into a normal poll or select backend and use it 441You still can embed kqueue into a normal poll or select backend and use it
437only for sockets (after having made sure that sockets work with kqueue on 442only for sockets (after having made sure that sockets work with kqueue on
438the target platform). See C<ev_embed> watchers for more info. 443the target platform). See C<ev_embed> watchers for more info.
439 444

Diff Legend

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