In the kqueue backend, do not report EBADF as an EV_READ

We were doing this because of (correct) reports that NetBSD gives an
EBADF when you try to add the write side of a pipe for which the
read side has been closed.  But on most kqueue platforms, that
doesn't happen, and on *all* kqueue platforms, reporting a
nonexistent fd (which we usually have if we have seen EBADF) as
readable tends to give programs a case of the vapors.

Nicholas Marriott wrote the original patch here; I did the comment
fixes.

diff --git a/kqueue.c b/kqueue.c
index 597eb4c65b70442d3b229e03a3ad4f6737095d45..81ae84e165c2344f0a1a086d013f97017fbd73c4 100644 (file)
--- a/kqueue.c
+++ b/kqueue.c
@@ -335,10 +335,15 @@ kq_dispatch(struct event_base *base, struct timeval *tv)
                        case EINVAL:
                                continue;
 
-                       /* Can occur on a delete if the fd is closed.  Can
-                        * occur on an add if the fd was one side of a pipe,
-                        * and the other side was closed. */
+                       /* Can occur on a delete if the fd is closed. */
                        case EBADF:
+                               /* XXXX On NetBSD, we can also get EBADF if we
+                                * try to add the write side of a pipe, but
+                                * the read side has already been closed.
+                                * Other BSDs call this situation 'EPIPE'. It
+                                * would be good if we had a way to report
+                                * this situation. */
+                               continue;
                        /* These two can occur on an add if the fd was one side
                         * of a pipe, and the other side was closed. */
                        case EPERM: