I just got a one-off, non-reproducible test_kqueue failure, during a 'make 
test' of the trunk, on OS X 10.5.6.  Here's the output:

test_kqueue
test test_kqueue failed -- Traceback (most recent call last):
  File "/Users/dickinsm/python_source/trunk/Lib/test/test_kqueue.py", line 
136, in test_queue_event
    (server.fileno(), select.KQ_FILTER_READ, flags)])
AssertionError: [(5L, -2, 5L), (6L, -2, 5L), (6L, -1, 5L)] != [(5, -2, 5), 
(5, -1, 5), (6, -2, 5), (6, -1, 5)]

Looking at the test_queue.py file just before line 136, I see:

        events = kq.control(None, 4, 1)
        # We may need to call it several times
        for i in range(5):
            if len(events) == 4:
                break
            events = kq.control(None, 4, 1)

Would adding a time.sleep(1.0) to the for loop make this test more robust?

My first impression was that the '1' in 'kq.control(None, 4, 1)' already 
did this;  i.e., that it meant that the kq.control function would wait up 
to 1 second for a response, but that doesn't seem to be true.  I tried 
replacing the 1 with 1000000 and the test still runs nearly 
instantaneously, even in the case where the kq.control call doesn't get 4 
events first time around.

Out of curiosity, *why* is there a need to call this several times? I 
fully believe there *is* such a need;  I just don't know what it is.  
Something to do with waiting for the socket send calls to complete, I 
assume?

> My first impression was that the '1' in 'kq.control(None, 4, 1)'
already did this;  i.e., that it meant that the kq.control function
would wait up to 1 second for a response, but that doesn't seem to be true.

Since there are events in the result, the call succeeds immediately. 
The timeout only defines an upper bound on how long control will block
before returning with *no* results.  Since the loop doesn't handle any
of the events, there's always some ready right away after the first call.

> Out of curiosity, *why* is there a need to call this several times?

It's out of the control of the test what the kernel does to deliver the
event notifications.  Since the test is waiting for multiple events, the
loop helps it get them all (although clearly it's not totally reliable).

Here's a patch:

 - add a time.sleep(1.0) in between calls to kq.control
 - restructure for loop slightly: move initial kq.control call inside it 
 - bump number of trials from 5 to 10 (why not?!)
 - produce more meaningful error message in the unlikely event
   that we never get the 4 events we're waiting for

I just saw this same test_kqueue failure pop up on the OS X 3.x buildbot,
so it's evidently not just a peculiarity of my machine.

Unless there are any objections, I'll go ahead and check this in:  I think 
it's a sufficiently trivial fix that it's not worth wasting Christian's 
time with. :)

Fixed in the trunk in r68897.  Will merge to 2.6, 3.0 and 3.1.