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.
