Lines Matching refs:backend
462 =item C<EVBACKEND_SELECT> (value 1, portable select backend)
464 This is your standard select(2) backend. Not I<completely> standard, as
467 using this backend. It doesn't scale too well (O(highest_fd)), but its
468 usually the fastest backend for a low number of (low-numbered :) fds.
470 To get good performance out of this backend you need a high amount of
477 This backend maps C<EV_READ> to the C<readfds> set and C<EV_WRITE> to the
481 =item C<EVBACKEND_POLL> (value 2, poll backend, available everywhere except on windows)
483 And this is your standard poll(2) backend. It's more complicated
490 This backend maps C<EV_READ> to C<POLLIN | POLLERR | POLLHUP>, and
498 For few fds, this backend is a bit little slower than poll and select, but
538 Best performance from this backend is achieved by not unregistering all
553 This backend maps C<EV_READ> and C<EV_WRITE> in the same way as
568 You still can embed kqueue into a normal poll or select backend and use it
572 It scales in the same way as the epoll backend, but the interface to the
580 This backend usually performs well under most conditions.
589 This backend maps C<EV_READ> into an C<EVFILT_READ> kevent with
597 and is not embeddable, which would limit the usefulness of this backend
605 While this backend scales well, it requires one system call per active
607 descriptors a "slow" C<EVBACKEND_SELECT> or C<EVBACKEND_POLL> backend
610 On the positive side, this backend actually performed fully to
625 This backend maps C<EV_READ> and C<EV_WRITE> in the same way as
635 C<ev_recommended_backends ()> returns, or simply do not specify a backend
640 Not a backend at all, but a mask to select all backend bits from a
646 If one or more of the backend flags are or'ed into the flags value,
707 costly reset of the backend).
756 Returns one of the C<EVBACKEND_*> flags indicating the event backend in
3130 =head2 C<ev_embed> - when one backend isn't enough...
3140 As an example for a bug workaround, the kqueue backend might only support
3141 sockets on some platform, so it is unusable as generic backend, but you
3241 a kqueue backend for use with sockets (which usually work with any
3559 Feed an event on the given fd, as if a file descriptor backend detected
4391 ev_select.c only when select backend is enabled (which is enabled by default)
4392 ev_poll.c only when poll backend is enabled (disabled by default)
4393 ev_epoll.c only when the epoll backend is enabled (disabled by default)
4394 ev_kqueue.c only when the kqueue backend is enabled (disabled by default)
4395 ev_port.c only when the solaris port backend is enabled (disabled by default)
4397 F<ev.c> includes the backend files directly when enabled, so you only need
4527 C<select>(2) backend. No attempt at auto-detection will be done: if no
4528 other method takes over, select will be it. Otherwise the select backend
4533 If defined to C<1>, then the select backend will use the system C<fd_set>
4543 When defined to C<1>, the select backend will assume that
4583 backend. Otherwise it will be enabled on non-win32 platforms. It
4589 C<epoll>(7) backend. Its availability will be detected at runtime,
4591 backend for GNU/Linux systems. If undefined, it will be enabled if the
4597 C<kqueue>(2) backend. Its actual availability will be detected at runtime,
4599 backend for BSD and BSD-like systems, although on most BSDs kqueue only
4609 10 port style backend. Its availability will be detected at runtime,
4611 backend for Solaris 10 systems.
4722 backend, use this:
4780 least one backend manually (C<EV_USE_SELECT> is a good choice).
5086 as if it were a bug in libev (e.g. in realloc or in the poll backend,
5170 =head3 Event port backend
5187 this by trying to avoid the poll backend altogether (i.e. it's not even
5198 the form of the C<EVBACKEND_SELECT> backend, and only supports socket
5292 backend-specific APIs, libev relies on a few additional extensions:
5403 on backend and whether C<ev_io_set> was used).
5501 =item backend