From 19558ed3ee597637d6cf3449845af3b29bb300a8 Mon Sep 17 00:00:00 2001
From: root <root>
Date: Sat, 13 Sep 2008 19:14:21 +0000
Subject: *** empty log message ***

---
 ev.pod | 17 +++++++++++++++++
 1 file changed, 17 insertions(+)

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
-- 
cgit v1.2.3