summaryrefslogtreecommitdiff
path: root/kqueue.c
diff options
context:
space:
mode:
authorNick Mathewson <nickm@torproject.org>2012-02-10 11:24:51 -0500
committerNick Mathewson <nickm@torproject.org>2012-02-10 11:24:51 -0500
commit5d7bfa1519b9dcfec4d9af8ca5cc5dc4e12c5156 (patch)
tree934cd1ac5ea89d8007b3a885ea0f10c0fc31498a /kqueue.c
parent19715a60e28ec2490bbdb45ab36921f5a47fc74d (diff)
downloadlibevent-5d7bfa1519b9dcfec4d9af8ca5cc5dc4e12c5156.tar.gz
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.
Diffstat (limited to 'kqueue.c')
-rw-r--r--kqueue.c11
1 files changed, 8 insertions, 3 deletions
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: