bpo-33530: Implement Happy Eyeballs in asyncio.#7097
bpo-33530: Implement Happy Eyeballs in asyncio.#7097twisteroidambassador wants to merge 60 commits into
Conversation
Added two keyword arguments, `delay` and `interleave`, to `BaseEventLoop.create_connection`. Happy eyeballs is activated if `delay` is specified.
|
Happy Eyeballs functionality should be working. All old tests pass (except A bit of gymnastics was required to keep the old behavior w.r.t. handling of multiple exceptions. |
Sorry, something went wrong.
bpo-32374, bpo-33629: Use support.SuppressCrashReport() in test_bad_traverse() of MultiPhaseExtensionModuleTests to prevent leaking a core dump file.
Use uuid_enc_be() if available to encode UUID to bytes as big endian.
runtest_mp.py: call print() with flush=True.
Pickles of type variables and subscripted generics are now future-proof and compatible with older Python versions.
…pythonGH-7134) The failure may be due to the use oF ZFS, a case we already ignore for Solaris-based systems where ZFS is frequently used.
…ythonGH-7149) Fixed bug where calling write_eof() on a _SelectorSocketTransport after it's already closed raises AttributeError.
…pythonGH-7130) In this commit: * Support BufferedProtocol in set_protocol() and start_tls() * Fix proactor to cancel readers reliably * Update tests to be compatible with OpenSSL 1.1.1 * Clarify BufferedProtocol docs * Bump TLS tests timeouts to 60 seconds; eliminate possible race from start_serving * Rewrite test_start_tls_server_1
Using -w, when failing tests are re-run in verbose mode, display again the tests results at the end.
…ows are correctly regenerated. (pythonGH-7165)
Original patch by Dan O'Reilly.
…-7216) Currently, asyncio.wait_for(fut), upon reaching the timeout deadline, cancels the future and returns immediately. This is problematic for when *fut* is a Task, because it will be left running for an arbitrary amount of time. This behavior is iself surprising and may lead to related bugs such as the one described in bpo-33638: condition = asyncio.Condition() async with condition: await asyncio.wait_for(condition.wait(), timeout=0.5) Currently, instead of raising a TimeoutError, the above code will fail with `RuntimeError: cannot wait on un-acquired lock`, because `__aexit__` is reached _before_ `condition.wait()` finishes its cancellation and re-acquires the condition lock. To resolve this, make `wait_for` await for the task cancellation. The tradeoff here is that the `timeout` promise may be broken if the task decides to handle its cancellation in a slow way. This represents a behavior change and should probably not be back-patched to 3.6 and earlier.
…ython#7217) Unlike `asyncio.wait_for()`, `asyncio.wait()` does not cancel the passed futures when a timeout accurs.
…GH-7208)" (python#7232) This reverts commit 5d97b7b.
…" (pythonGH-7235) This reverts commit ad74d50. Turns out it's not a good fix -- Travis has just crashed on this test.
Added two keyword arguments, `delay` and `interleave`, to `BaseEventLoop.create_connection`. Happy eyeballs is activated if `delay` is specified.
|
Uh, I did a rebase against upstream, and seems like it brought in commits from other people into this pull request. Should I close this PR and open a new one? |
Sorry, something went wrong.
NP!
That's one way to fix it. Alternatively, you can just force-push a fixed branch and remove people from reviews/notifications. |
Sorry, something went wrong.
|
Seems there's no way we can remove devs that were accidentally subscribed to this PR. I'm closing this one, please submit a new PR. |
Sorry, something went wrong.
Added two keyword arguments,
delayandinterleave, toBaseEventLoop.create_connection. Happy eyeballs is activated ifdelayis specified.https://bugs.python.org/issue33530