From 5d7bfa1519b9dcfec4d9af8ca5cc5dc4e12c5156 Mon Sep 17 00:00:00 2001 From: Nick Mathewson Date: Fri, 10 Feb 2012 11:24:51 -0500 Subject: 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. --- kqueue.c | 11 ++++++++--- 1 file changed, 8 insertions(+), 3 deletions(-) (limited to 'kqueue.c') 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: -- cgit v1.2.1