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

Comparing libev/ev.pod (file contents):
Revision 1.447 by root, Sat Jun 22 16:25:53 2019 UTC vs.
Revision 1.453 by root, Tue Jun 25 05:01:22 2019 UTC

… …
574This backend maps C<EV_READ> and C<EV_WRITE> in the same way as 574This backend maps C<EV_READ> and C<EV_WRITE> in the same way as
575C<EVBACKEND_POLL>. 575C<EVBACKEND_POLL>.
576 576
577=item C<EVBACKEND_LINUXAIO> (value 64, Linux) 577=item C<EVBACKEND_LINUXAIO> (value 64, Linux)
578 578
579Use the linux-specific linux aio (I<not> C<< aio(7) >>) event interface 579Use the linux-specific linux aio (I<not> C<< aio(7) >> but C<<
580available in post-4.18 kernels. 580io_submit(2) >>) event interface available in post-4.18 kernels (but libev
581only tries to use it in 4.19+).
582
583This is another linux trainwreck of an event interface.
581 584
582If this backend works for you (as of this writing, it was very 585If this backend works for you (as of this writing, it was very
583experimental and only supports a subset of file types), it is the best 586experimental), it is the best event interface available on linux and might
584event interface available on linux and might be well worth it enabling it 587be well worth enabling it - if it isn't available in your kernel this will
585- if it isn't available in your kernel this will be detected and another 588be detected and this backend will be skipped.
586backend will be chosen.
587 589
588This backend can batch oneshot requests and uses a user-space ring buffer 590This backend can batch oneshot requests and supports a user-space ring
589to receive events. It also doesn't suffer from most of the design problems 591buffer to receive events. It also doesn't suffer from most of the design
590of epoll (such as not being able to remove event sources from the epoll 592problems of epoll (such as not being able to remove event sources from
591set), and generally sounds too good to be true. Because, this being the 593the epoll set), and generally sounds too good to be true. Because, this
592linux kernel, of course it suffers from a whole new set of limitations. 594being the linux kernel, of course it suffers from a whole new set of
595limitations, forcing you to fall back to epoll, inheriting all its design
596issues.
593 597
594For one, it is not easily embeddable (but probably could be done using 598For one, it is not easily embeddable (but probably could be done using
595an event fd at some extra overhead). It also is subject to various 599an event fd at some extra overhead). It also is subject to a system wide
596arbitrary limits that can be configured in F</proc/sys/fs/aio-max-nr> 600limit that can be configured in F</proc/sys/fs/aio-max-nr>. If no aio
597and F</proc/sys/fs/aio-nr>), which could lead to it being skipped during 601requests are left, this backend will be skipped during initialisation, and
598initialisation. 602will switch to epoll when the loop is active.
599 603
600Most problematic in practise, however, is that, like kqueue, it requires 604Most problematic in practice, however, is that not all file descriptors
601special support from drivers, and, not surprisingly, not all drivers
602implement it. For example, in linux 4.19, tcp sockets, pipes, event fds, 605work with it. For example, in linux 5.1, tcp sockets, pipes, event fds,
603files, F</dev/null> and a few others are supported, but ttys are not, so 606files, F</dev/null> and a few others are supported, but ttys do not work
604this is not (yet?) a generic event polling interface but is probably still 607properly (a known bug that the kernel developers don't care about, see
605be very useful in a web server or similar program. 608L<https://lore.kernel.org/patchwork/patch/1047453/>), so this is not
609(yet?) a generic event polling interface.
610
611Overall, it seems the linux developers just don't want it to have a
612generic event handling mechanism other than C<select> or C<poll>.
613
614To work around all these problem, the current version of libev uses its
615epoll backend as a fallback for file descriptor types that do not work. Or
616falls back completely to epoll if the kernel acts up.
606 617
607This backend maps C<EV_READ> and C<EV_WRITE> in the same way as 618This backend maps C<EV_READ> and C<EV_WRITE> in the same way as
608C<EVBACKEND_POLL>. 619C<EVBACKEND_POLL>.
609 620
610=item C<EVBACKEND_KQUEUE> (value 8, most BSD clones) 621=item C<EVBACKEND_KQUEUE> (value 8, most BSD clones)
611 622
612Kqueue deserves special mention, as at the time of this writing, it 623Kqueue deserves special mention, as at the time this backend was
613was broken on all BSDs except NetBSD (usually it doesn't work reliably 624implemented, it was broken on all BSDs except NetBSD (usually it doesn't
614with anything but sockets and pipes, except on Darwin, where of course 625work reliably with anything but sockets and pipes, except on Darwin,
615it's completely useless). Unlike epoll, however, whose brokenness 626where of course it's completely useless). Unlike epoll, however, whose
616is by design, these kqueue bugs can (and eventually will) be fixed 627brokenness is by design, these kqueue bugs can be (and mostly have been)
617without API changes to existing programs. For this reason it's not being 628fixed without API changes to existing programs. For this reason it's not
618"auto-detected" unless you explicitly specify it in the flags (i.e. using 629being "auto-detected" on all platforms unless you explicitly specify it
619C<EVBACKEND_KQUEUE>) or libev was compiled on a known-to-be-good (-enough) 630in the flags (i.e. using C<EVBACKEND_KQUEUE>) or libev was compiled on a
620system like NetBSD. 631known-to-be-good (-enough) system like NetBSD.
621 632
622You still can embed kqueue into a normal poll or select backend and use it 633You still can embed kqueue into a normal poll or select backend and use it
623only for sockets (after having made sure that sockets work with kqueue on 634only for sockets (after having made sure that sockets work with kqueue on
624the target platform). See C<ev_embed> watchers for more info. 635the target platform). See C<ev_embed> watchers for more info.
625 636

Diff Legend

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