apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Orton <jor...@redhat.com>
Subject Re: testpoll.c:multi_event_pollset and 1.2.x
Date Wed, 15 Mar 2006 12:30:07 GMT
On Wed, Mar 15, 2006 at 12:09:06PM +0000, Joe Orton wrote:
> On Tue, Mar 14, 2006 at 01:19:31PM -0800, Garrett Rooney wrote:
> > Does anyone have an objection to reverting the addition of the new
> > multi_event_pollset test on the 1.2.x branch?  It's testing for
> > behavior that's never existed for a number of pollset back ends (at
> > least kqueue, potentially epoll as well), and nobody has jumped up to
> > make the test pass on those platforms in trunk, let alone get a fix
> > that can be backported.
> > 
> > For the curious, the problem is that kqueue doesn't consolidate the
> > events it returns, so you can get two separate events for the same
> > file descriptor, some read, some write, etc.
> > 
> > Given that we've always had this behavior in the 1.x releases and
> > nobody's complained about it, I'm willing to just say that the test is
> > bogus.  If someone wants to rework the kqueue (and probably epoll)
> > impls to meet this new standard that's something that can be
> > discussed, but for now there's no real justification for us to
> > suddenly condemn their behavior.
> Returning two separate descriptors should be valid behaviour, the test 
> just needs to be adjusted to handle that case; it'll still catch the bug 
> in the select() backend.  Can you try this patch?

Ah, sorry, I see Brian had already posted an almost identical patch.  
With either this or his patch applied, the test looks correct to me.  
After the recv_msg call there should not be available data to read from 
the socket, so if rtnevents has POLLIN set at that point, it sounds like 
a real bug.


View raw message