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?