--- libev/ev.pod	2008/09/13 18:25:50	1.178
+++ libev/ev.pod	2008/09/13 19:14:21	1.179
@@ -361,6 +361,10 @@
 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 @@
 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 @@
 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 @@
 (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 @@
 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