bpo-34130: Fix test_signal.test_warn_on_full_buffer() #8327
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Oh. test_warn_on_full_buffer() still fails randomly with this PR :-( |
On Windows, sometimes test_signal.test_warn_on_full_buffer() fails to fill the socketpair buffer. In that case, the C signal handler succeed to write into the socket, it doesn't log the expected send error, and so the test fail. On Windows, the test now uses a timeout of 50 ms to fill the socketpair buffer to fix this race condition. Other changes: * Being with large chunk size to fill the buffer to speed up the test. * Add error messages to assertion errors to more easily identify which assertion failed. * Don't set the read end of the socketpair as non-blocking.
|
Hum, I rewrote my PR 3 times. My first attempts were optimistic: loop until non-blocking send() stop failing with BlockingIOError. My latest PR uses a timeout of 50 ms as a workaround for the issue. |
|
Without my PR, test_warn_on_full_buffer() takes 4.2 seconds because of the inefficient loop filling the socketpair. With this PR, the test now only takes 600 ms: it's now 7x faster even with the additional timeouts. |
vstinner
added a commit
that referenced
this pull request
Jul 18, 2018
* bpo-34130: Fix test_signal.test_socket() (GH-8326) test_signal.test_socket(): On Windows, sometimes even if the C signal handler succeed to write the signal number into the write end of the socketpair, the test fails with a BlockingIOError on the non-blocking read.recv(1) because the read end of the socketpair didn't receive the byte yet. Fix the race condition on Windows by setting the read end as blocking. (cherry picked from commit 99bb6df) * bpo-34130: Fix test_signal.test_warn_on_full_buffer() (GH-8327) On Windows, sometimes test_signal.test_warn_on_full_buffer() fails to fill the socketpair buffer. In that case, the C signal handler succeed to write into the socket, it doesn't log the expected send error, and so the test fail. On Windows, the test now uses a timeout of 50 ms to fill the socketpair buffer to fix this race condition. Other changes: * Begin with large chunk size to fill the buffer to speed up the test. * Add error messages to assertion errors to more easily identify which assertion failed. * Don't set the read end of the socketpair as non-blocking. (cherry picked from commit 686b4b5)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Sometimes on Windows, test_signal.test_warn_on_full_buffer() fails on
fill the socketpair buffer, the C signal handler succeed to write
into the socket and so doesn't log the expected send error, and the
test fail.
Retry the test a second time if the first attempt failed to fill the
buffer.
Speed-up also the code filling the socketpair: being with writing
64 KiB chunks, instead of only write byte per byte.
Add also error messages to assertion errors to more easily identify
which assertion failed.
https://bugs.python.org/issue34130