I'd be inclined to go with 3 too, it would be nice if all were
consistent as can be in the long run to avoid similar problems later.
It looks like NetBSD has returned EBADF here (sys_pipe.c:pipe_kqfilter)
since 2002 but it's a pretty easy change, maybe they'd like to make it
consistent. It sort of sucks not being able to tell which end was
closed.
On Thu, Feb 09, 2012 at 04:50:14PM -0500, Nick Mathewson wrote:
> On Thu, Feb 9, 2012 at 3:37 PM, Frank Denis <libev...@pureftpd.org> wrote:
> > Le Thu, Feb 09, 2012 at 03:23:32PM -0500, Nick Mathewson ecrivait :
> >> On Thu, Feb 9, 2012 at 4:32 AM, Nicholas Marriott
> >> I'm asking around; I'll let you know if anybody tells me they can test
> >> NetBSD.
> >
> > $ ./a
> > pipefd[0] = {4,5}
> > pipefd[1] = {6,7}
> > pipefd[2] = {8,9}
> > pipefd[3] = {10,11}
> > 1 events:
> > ?9: filter=1 flags=4000 error=9 [Bad file descriptor]
> > 3 events:
> > ?4: filter=0 flags=8001
> > ?11: filter=1 flags=8001
> > ?6: filter=0 flags=8001
> >
> > $ uname -a
> > NetBSD ?5.1.2 NetBSD 5.1.2 (GENERIC) #0: Thu Feb ?2 12:12:28 UTC 2012
> > ?bui...@b7.netbsd.org:/home/builds/ab/netbsd-5-1-2-RELEASE/amd64/201202021012Z-obj/home/builds/ab/netbsd-5-1-2-RELEASE/src/sys/arch/amd64/compile/GENERIC
> > amd64
>
> And Linus Norberg reports:
>
> =====
> bash-4.1$ uname -a
> ... NetBSD 5.0_STABLE ...
>
> bash-4.1$ ./a.out
> pipefd[0] = {4,5}
> pipefd[1] = {6,7}
> pipefd[2] = {8,9}
> pipefd[3] = {10,11}
> 1 events:
> 9: filter=1 flags=4000 error=9 [Bad file descriptor]
> 3 events:
> 4: filter=0 flags=8001
> 11: filter=1 flags=8001
> 6: filter=0 flags=8001
> bash-4.1$
> =====
>
> So it looks like our initial reports of NetBSD giving EBADF for this
> situation were accurate: When adding the write side of a pipe to a
> write filter, if the read side has already been closed, NetBSD tells
> us "EBADF."
>
> Some options:
>
> 1) Go with Nicholas Marriott's patch, which makes everybody's EBADF
> get ignored, since it is _mostly_ something to ignore.
> 2) As 1 above, but keep the current behavior on NetBSD, where it
> might be helpful somehow, though I kinda doubt it, since reporting
> this as EV_READ is a bit silly.
> 3) As 1 above, and try to make all the backends as consistent as we
> can for this case in 2.1.
> 4) As 3 above, but try to make all the backends consistent right now.
> 5) other
>
> Personally, I'm inclined to go with 3, since it tries to minimize
> added cleverness in 2.0, but also tries to get stuff right eventually.
>
> Thoughts? I plan to merge something here tonight or tomorrow, then
> put out another release then or this weekend.
>
> yrs,
> --
> Nick
> ***********************************************************************
> To unsubscribe, send an e-mail to majord...@freehaven.net with
> unsubscribe libevent-users in the body.
***********************************************************************
To unsubscribe, send an e-mail to majord...@freehaven.net with
unsubscribe libevent-users in the body.
