On 3/15/06, Joe Orton <[EMAIL PROTECTED]> wrote: > 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.
I can't recall if I tested Brian's old patch on FreeBSD or Darwin. It's quite possible I tested on Darwin, which as we now know has some bustedness in its kqueue support. I'll try and give it a shot on something with a working kqueue today. -garrett
