-
Notifications
You must be signed in to change notification settings - Fork 652
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Wait for closeFuture
instead of close promise in NIOAsyncChannel
's executeThenClose
#3032
Conversation
f3ed6fe
to
d050010
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM!
// at this point. | ||
self.channel.close(promise: nil) | ||
// `closeFuture` is never failed, so we can ignore the error | ||
try? await self.channel.closeFuture.get() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure whether we decided to ignore closeFuture
errors entirely or not – it seems completely reasonable to ignore them though.
Suspect @FranzBusch has opinions.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This future should never be failed; if we're considering a failing closeFuture
the result of a bad implementation of a Channel
but not something that should happen in any other scenario, it seemed reasonable to me to ignore all errors.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The original goals were:
- Make sure we only excited from
executeThenClose
when the channel is actually closed - Surface any errors if closing fails
Now 1. is still being upheld here since we wait for the closeFuture
. It also turns out that closing can't fail and a call to close()
must always result in the closeFuture completing. Strictly speaking succeeding actually.
Now we have two options here. We can just assume that the "strict" part is true so there will never be any errors. However, there might be some code out there that actually fails the close future. What if we catch the error and add an assert that triggers if this close future actually fails to help us spot incorrect implementations?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree, it just depends whether we want to help flush out the different implementations or not.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fair enough, adding an assertion sounds useful.
After the changes introduced in apple/swift-nio-http2#487, we need to make a small change in the implementation of
NIOAsyncChannel
to wait on thecloseFuture
instead of onclose
's promise in theexecuteThenClose
implementation.Motivation:
executeThenClose
shouldn't fail from errors arising from closing the channel - at this point, the user of the channel cannot really do anything, and since the channel has been closed, we should not fail since resources have been cleaned up anyways.Modifications:
This PR changes the implementation of
NIOAsyncChannel
to wait on thecloseFuture
instead of onclose
's promise in theexecuteThenClose
implementation.It also updates the docs for
closeFuture
to better explain when it will be succeeded and why it won't ever be failed.Result:
executeThenClose
won't throw errors upon closing.