cuberite/libevent
1
0
Fork 0
mirror of https://github.com/cuberite/libevent.git synced 2025-09-08 11:53:00 -04:00
Code Issues Packages Projects Releases Wiki Activity

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

Browse Source 
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.
This commit is contained in:
Nick Mathewson 2012-02-10 11:24:51 -05:00
parent 19715a60e2
commit 5d7bfa1519
1 changed files with 8 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

11
kqueue.c
View File

@ -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: