Attempt to fix (or workaround) test__socket.py on Windows.
It runs locally for me on Win10/Py3.6 with both libev and libuv. It had been sometimes failing since 2016-02 for 2.7 and 2016-04 for 3.5. Here's the comment in the code indicating what I tracked down. Note that the changes are more of a workaround than a true fix: XXX: On Windows (at least with libev), if we have a cleanup/tearDown method that does 'del self.listener' AND we haven't sometime previously closed the listener (while the test body was executing) we tend to sometimes see hangs when tests run in succession; notably test_empty_send followed by test_makefile produces a hang in test_makefile when it tries to read from the client_file, because the accept() call in accept_once has not yet returned a new socket to write to. The cause *seems* to be that the listener socket in both tests gets the same fileno(); or, at least, if we don't del the listener object, we get a different fileno, and that scenario works. Perhaps our logic is wrong in libev_vfd in the way we use _open_osfhandle and determine we can close it? Additional note: Possibly libuv doesn't suffer from this since it takes the SOCKET object directly? I didn't fully test that situation, but libuv tests were failing and are now passing.
Showing
Please register or sign in to comment