summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
-rw-r--r--ev.pod17
1 files changed, 17 insertions, 0 deletions
diff --git a/ev.pod b/ev.pod
index 55c78b0..1eb4ecb 100644
--- a/ev.pod
+++ b/ev.pod
@@ -361,6 +361,10 @@ connections as possible during one iteration. You might also want to have
a look at C<ev_set_io_collect_interval ()> to increase the amount of
readiness notifications you get per iteration.
+This backend maps C<EV_READ> to the C<readfds> set and C<EV_WRITE> to the
+C<writefds> set (and to work around Microsoft Windows bugs, also onto the
+C<exceptfds> set on that platform).
+
=item C<EVBACKEND_POLL> (value 2, poll backend, available everywhere except on windows)
And this is your standard poll(2) backend. It's more complicated
@@ -370,6 +374,9 @@ considerably with a lot of inactive fds). It scales similarly to select,
i.e. O(total_fds). See the entry for C<EVBACKEND_SELECT>, above, for
performance tips.
+This backend maps C<EV_READ> to C<POLLIN | POLLERR | POLLHUP>, and
+C<EV_WRITE> to C<POLLOUT | POLLERR | POLLHUP>.
+
=item C<EVBACKEND_EPOLL> (value 4, Linux)
For few fds, this backend is a bit little slower than poll and select,
@@ -397,6 +404,9 @@ keep at least one watcher active per fd at all times.
While nominally embeddable in other event loops, this feature is broken in
all kernel versions tested so far.
+This backend maps C<EV_READ> and C<EV_WRITE> in the same way as
+C<EVBACKEND_POLL>.
+
=item C<EVBACKEND_KQUEUE> (value 8, most BSD clones)
Kqueue deserves special mention, as at the time of this writing, it
@@ -427,6 +437,10 @@ almost everywhere, you should only use it when you have a lot of sockets
(e.g. C<EVBACKEND_SELECT> or C<EVBACKEND_POLL>) and using it only for
sockets.
+This backend maps C<EV_READ> into an C<EVFILT_READ> kevent with
+C<NOTE_EOF>, and C<EV_WRITE> into an C<EVFILT_WRITE> kevent with
+C<NOTE_EOF>.
+
=item C<EVBACKEND_DEVPOLL> (value 16, Solaris 8)
This is not implemented yet (and might never be, unless you send me an
@@ -452,6 +466,9 @@ On the positive side, ignoring the spurious readiness notifications, this
backend actually performed to specification in all tests and is fully
embeddable, which is a rare feat among the OS-specific backends.
+This backend maps C<EV_READ> and C<EV_WRITE> in the same way as
+C<EVBACKEND_POLL>.
+
=item C<EVBACKEND_ALL>
Try all backends (even potentially broken ones that wouldn't be tried