| … | |
… | |
| 567 | |
567 | |
| 568 | It scales in the same way as the epoll backend, but the interface to the |
568 | It scales in the same way as the epoll backend, but the interface to the |
| 569 | kernel is more efficient (which says nothing about its actual speed, of |
569 | kernel is more efficient (which says nothing about its actual speed, of |
| 570 | course). While stopping, setting and starting an I/O watcher does never |
570 | course). While stopping, setting and starting an I/O watcher does never |
| 571 | cause an extra system call as with C<EVBACKEND_EPOLL>, it still adds up to |
571 | cause an extra system call as with C<EVBACKEND_EPOLL>, it still adds up to |
| 572 | two event changes per incident. Support for C<fork ()> is very bad (but |
572 | two event changes per incident. Support for C<fork ()> is very bad (you |
| 573 | sane, unlike epoll) and it drops fds silently in similarly hard-to-detect |
573 | might have to leak fd's on fork, but it's more sane than epoll) and it |
| 574 | cases |
574 | drops fds silently in similarly hard-to-detect cases |
| 575 | |
575 | |
| 576 | This backend usually performs well under most conditions. |
576 | This backend usually performs well under most conditions. |
| 577 | |
577 | |
| 578 | While nominally embeddable in other event loops, this doesn't work |
578 | While nominally embeddable in other event loops, this doesn't work |
| 579 | everywhere, so you might need to test for this. And since it is broken |
579 | everywhere, so you might need to test for this. And since it is broken |
