mirror of /home/gitosis/repositories/libev.git
*** empty log message ***
This commit is contained in:
parent
e7b6bda15c
commit
78aad029fa
47
ev.3
47
ev.3
|
@ -133,7 +133,7 @@
|
|||
.\" ========================================================================
|
||||
.\"
|
||||
.IX Title "LIBEV 3"
|
||||
.TH LIBEV 3 "2019-06-22" "libev-4.25" "libev - high performance full featured event loop"
|
||||
.TH LIBEV 3 "2019-06-23" "libev-4.25" "libev - high performance full featured event loop"
|
||||
.\" For nroff, turn off justification. Always turn off hyphenation; it makes
|
||||
.\" way too many mistakes in technical documents.
|
||||
.if n .ad l
|
||||
|
@ -703,33 +703,36 @@ This backend maps \f(CW\*(C`EV_READ\*(C'\fR and \f(CW\*(C`EV_WRITE\*(C'\fR in th
|
|||
.ie n .IP """EVBACKEND_LINUXAIO"" (value 64, Linux)" 4
|
||||
.el .IP "\f(CWEVBACKEND_LINUXAIO\fR (value 64, Linux)" 4
|
||||
.IX Item "EVBACKEND_LINUXAIO (value 64, Linux)"
|
||||
Use the linux-specific linux aio (\fInot\fR \f(CWaio(7)\fR) event interface
|
||||
available in post\-4.18 kernels.
|
||||
Use the linux-specific linux aio (\fInot\fR \f(CWaio(7)\fR but \f(CWio_submit(2)\fR) event interface available in post\-4.18 kernels.
|
||||
.Sp
|
||||
If this backend works for you (as of this writing, it was very
|
||||
experimental and only supports a subset of file types), it is the best
|
||||
event interface available on linux and might be well worth it enabling it
|
||||
\&\- if it isn't available in your kernel this will be detected and another
|
||||
backend will be chosen.
|
||||
experimental), it is the best event interface available on linux and might
|
||||
be well worth enabling it \- if it isn't available in your kernel this will
|
||||
be detected and this backend will be skipped.
|
||||
.Sp
|
||||
This backend can batch oneshot requests and uses a user-space ring buffer
|
||||
to receive events. It also doesn't suffer from most of the design problems
|
||||
of epoll (such as not being able to remove event sources from the epoll
|
||||
set), and generally sounds too good to be true. Because, this being the
|
||||
linux kernel, of course it suffers from a whole new set of limitations.
|
||||
This backend can batch oneshot requests and supports a user-space ring
|
||||
buffer to receive events. It also doesn't suffer from most of the design
|
||||
problems of epoll (such as not being able to remove event sources from
|
||||
the epoll set), and generally sounds too good to be true. Because, this
|
||||
being the linux kernel, of course it suffers from a whole new set of
|
||||
limitations.
|
||||
.Sp
|
||||
For one, it is not easily embeddable (but probably could be done using
|
||||
an event fd at some extra overhead). It also is subject to various
|
||||
arbitrary limits that can be configured in \fI/proc/sys/fs/aio\-max\-nr\fR
|
||||
and \fI/proc/sys/fs/aio\-nr\fR), which could lead to it being skipped during
|
||||
initialisation.
|
||||
an event fd at some extra overhead). It also is subject to a system wide
|
||||
limit that can be configured in \fI/proc/sys/fs/aio\-max\-nr\fR \- each loop
|
||||
currently requires \f(CW61\fR of this number. If no aio requests are left, this
|
||||
backend will be skipped during initialisation.
|
||||
.Sp
|
||||
Most problematic in practise, however, is that, like kqueue, it requires
|
||||
special support from drivers, and, not surprisingly, not all drivers
|
||||
implement it. For example, in linux 4.19, tcp sockets, pipes, event fds,
|
||||
files, \fI/dev/null\fR and a few others are supported, but ttys are not, so
|
||||
this is not (yet?) a generic event polling interface but is probably still
|
||||
be very useful in a web server or similar program.
|
||||
Most problematic in practise, however, is that not all file descriptors
|
||||
work with it. For example, in linux 5.1, tcp sockets, pipes, event fds,
|
||||
files, \fI/dev/null\fR and a few others are supported, but ttys do not work
|
||||
(probably because of a bug), so this is not (yet?) a generic event polling
|
||||
interface.
|
||||
.Sp
|
||||
To work around this latter problem, the current version of libev uses
|
||||
epoll as a fallback for file deescriptor types that do not work. Epoll
|
||||
is used in, kind of, slow mode that hopefully avoids most of its design
|
||||
problems and requires 1\-3 extra syscalls per active fd every iteration.
|
||||
.Sp
|
||||
This backend maps \f(CW\*(C`EV_READ\*(C'\fR and \f(CW\*(C`EV_WRITE\*(C'\fR in the same way as
|
||||
\&\f(CW\*(C`EVBACKEND_POLL\*(C'\fR.
|
||||
|
|
Loading…
Reference in New Issue