Re: [Libevent-users] [nicholas.marriott@xxxxxxxxx: libevent and invalid fds]

[Nicholas Marriott <nicholas.marriott@xxxxxxxxx>]

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 <libevent@xxxxxxxxxxxx> 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 ?builds@xxxxxxxxxxxxx:/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 majordomo@xxxxxxxxxxxxx with
> unsubscribe libevent-users    in the body.
***********************************************************************
To unsubscribe, send an e-mail to majordomo@xxxxxxxxxxxxx with
unsubscribe libevent-users    in the body.