| … | |
… | |
| 584 | be well worth enabling it - if it isn't available in your kernel this will |
584 | be well worth enabling it - if it isn't available in your kernel this will |
| 585 | be detected and this backend will be skipped. |
585 | be detected and this backend will be skipped. |
| 586 | |
586 | |
| 587 | This backend can batch oneshot requests and supports a user-space ring |
587 | This backend can batch oneshot requests and supports a user-space ring |
| 588 | buffer to receive events. It also doesn't suffer from most of the design |
588 | buffer to receive events. It also doesn't suffer from most of the design |
| 589 | problems of epoll (such as not being able to remove event sources from |
589 | problems of epoll (such as not being able to remove event sources from the |
| 590 | the epoll set), and generally sounds too good to be true. Because, this |
590 | epoll set), and generally sounds too good to be true. Because, this being |
| 591 | being the linux kernel, of course it suffers from a whole new set of |
591 | the linux kernel, of course it suffers from a whole new set of limitations. |
| 592 | limitations. |
|
|
| 593 | |
592 | |
| 594 | For one, it is not easily embeddable (but probably could be done using |
593 | For one, it is not easily embeddable (but probably could be done using |
| 595 | an event fd at some extra overhead). It also is subject to a system wide |
594 | an event fd at some extra overhead). It also is subject to a system wide |
| 596 | limit that can be configured in F</proc/sys/fs/aio-max-nr> - each loop |
595 | limit that can be configured in F</proc/sys/fs/aio-max-nr> - each loop |
| 597 | currently requires C<61> of this number. If no aio requests are left, this |
596 | currently requires C<61> of this number. If no aio requests are left, this |
| … | |
… | |
| 602 | files, F</dev/null> and a few others are supported, but ttys do not work |
601 | files, F</dev/null> and a few others are supported, but ttys do not work |
| 603 | properly (a known bug that the kernel developers don't care about, see |
602 | properly (a known bug that the kernel developers don't care about, see |
| 604 | L<https://lore.kernel.org/patchwork/patch/1047453/>), so this is not |
603 | L<https://lore.kernel.org/patchwork/patch/1047453/>), so this is not |
| 605 | (yet?) a generic event polling interface. |
604 | (yet?) a generic event polling interface. |
| 606 | |
605 | |
|
|
606 | Overall, it seems the linux developers just don't want it to have a |
|
|
607 | generic event handling mechanism other than C<select> or C<poll>. |
|
|
608 | |
| 607 | To work around this latter problem, the current version of libev uses |
609 | To work around the fd type problem, the current version of libev uses |
| 608 | epoll as a fallback for file deescriptor types that do not work. Epoll |
610 | epoll as a fallback for file deescriptor types that do not work. Epoll |
| 609 | is used in, kind of, slow mode that hopefully avoids most of its design |
611 | is used in, kind of, slow mode that hopefully avoids most of its design |
| 610 | problems and requires 1-3 extra syscalls per active fd every iteration. |
612 | problems and requires 1-3 extra syscalls per active fd every iteration. |
| 611 | |
613 | |
| 612 | This backend maps C<EV_READ> and C<EV_WRITE> in the same way as |
614 | This backend maps C<EV_READ> and C<EV_WRITE> in the same way as |
