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. joe
