Issue 5025: test_kqueue failure on OS X (original) (raw)

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