HappyEyeballs should tolerate uncancellable tasks. #191
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
normanmaurer
approved these changes
Mar 19, 2018
| channels.finishAll() | ||
| } | ||
|
|
||
| let (eyeballer, resolver, loop) = buildEyeballer(host: "example.com", port: 80, connectTimeout: .milliseconds(250)) { |
There was a problem hiding this comment.
@Lukasa maybe we just want to use swiftnio.io for the hostname everywhere tho ?
There was a problem hiding this comment.
I think it doesn't really matter?
There was a problem hiding this comment.
Yeah sure it not matters in this test but if we have a domain name we can also just use it and not refer to some random ones. Feel free to ignore tho, I don’t say we need to do it but I think knit is a good thing in general
There was a problem hiding this comment.
Actually, an example.com is just OK for this purpose, see rfc2606.
|
@Lukasa can you rebase and merge ? |
Lukasa
force-pushed
the
cb-handle-cancellation-of-delayed-tasks
branch
from
a529bd5 to
20a1dbd
Compare
Motivation: The HappyEyeballs state machine incorrectly assumed that it would always be able to cancel any scheduled task that would execute on the event loop that the state machine itself was running on. This is not accurate: if the scheduled task is scheduled to execute at roughly the same time as another callback into the state machine then it may be uncancellable. Modifications: Allowed the three scheduled tasks (connect timeout, connect delay, and resolver delay) to fire in completed. Result: No fatalErrors in window conditions under high load
Lukasa
force-pushed
the
cb-handle-cancellation-of-delayed-tasks
branch
from
20a1dbd to
02db81e
Compare
|
@swift-nio-bot test this please |
weissi
pushed a commit
to weissi/swift-nio
that referenced
this pull request
Jun 13, 2020
Motivation: When a window update event is received in the stream channel we notify the inbound window manager. Doing so may emit a WINDOW_UPDATE frame to indicate the remote may send us more DATA. However, this happens even if there are inbound frames waiting to be delivered to the channel. This may lead to the remote sending us more DATA which we have to buffer until it is read. Modifications: - Update the inbound window manager to track the number of bytes buffered in the stream channel - Account for buffered bytes when receiving a new window size event - Possibly emit WINDOW_UPDATE after unbuffering inbound frames into the stream channel's pipeline Result: The timing of WINDOW_UPDATE frames is better aligned with when frames are actually read in a stream.
weissi
pushed a commit
to weissi/swift-nio
that referenced
this pull request
Feb 3, 2024
Motivation: Docs are generated by and hosted on the Swift Package Index. We no longer need the script to generate docs via Jazzy. Modifications: - Remove the generate_docs script - Remove Jazzy from the Dockerfile but keep Ruby; it's used for generating test manifests. - Remove SwiftFormat from the Dockerfile; we don't use it. Result: Fewer unused things.
# for free
to join this conversation on GitHub.
Already have an account?
# 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.
Motivation:
The HappyEyeballs state machine incorrectly assumed that it would always
be able to cancel any scheduled task that would execute on the event loop
that the state machine itself was running on. This is not accurate: if
the scheduled task is scheduled to execute at roughly the same time as
another callback into the state machine then it may be uncancellable.
Modifications:
Allowed the three scheduled tasks (connect timeout, connect delay, and
resolver delay) to fire in completed.
Result:
No fatalErrors in window conditions under high load
Resolves #187.