From: Nick Mathewson <nickm@torproject.org>
Date: Fri, 10 Feb 2012 16:24:51 +0000 (-0500)
Subject: In the kqueue backend, do not report EBADF as an EV_READ
X-Git-Tag: release-2.0.17-stable~4
X-Git-Url: https://granicus.if.org/sourcecode?a=commitdiff_plain;h=5d7bfa1519b9dcfec4d9af8ca5cc5dc4e12c5156;p=libevent

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 597eb4c6..81ae84e1 100644
--- 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: