-
-
Notifications
You must be signed in to change notification settings - Fork 2.6k
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
udp: add into_parts
to RecvDgram
#710
Conversation
If `RecvDgram` can not be driven to completion it may become necessary to get back the `UdpSocket` it contains which is currently not possible. This commit adds `into_inner` to do just that and `into_parts` to get the socket as well as the buffer back. Both methods consume `RecvDgram`. Note that after the future has completed, neither `into_inner` nor `into_parts` must be used, or else a panic will happen.
for `RecvDgram::into_inner` and `RecvDgram::into_parts`
tokio-udp/src/recv_dgram.rs
Outdated
/// | ||
/// If called after the future has completed. | ||
pub fn into_inner(mut self) -> UdpSocket { | ||
let state = self.state |
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.
How about adding common private function to get the state?
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 am not sure it would be an improvement. It would essentially look like this:
fn into_state(mut self, msg: &str) -> RcvDgramInner {
self.state.take().expect(msg)
}
and the calls would be self.into_state("into_inner called after completion")
and self.into_state("into_parts called after completion")
which does not really seem clearer to me. Would you really like me to make this change?
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.
Is there a reason we want the into_inner
variant? Seems like we should just have into_parts
and people can drop the buffer if they don't want it.
@tobz: It is true that |
As suggested during review, `into_inner` is considered redundant and should be removed.
into_inner
and into_parts
to RecvDgram
into_parts
to RecvDgram
FYI: CI is failing with an internal compiler error (rustc 1.31.0-nightly) when compiling hyper which is unrelated to this PR. |
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.
(Yeah, that CI failure is weird.)
Although now I'm not sure I can merge this if it doesn't pass CI... |
The strategy of returning a tuple isn't very forwards compatbile. If That said, Do you think it is worth returning a |
To help future extensibility, avoid returning a tuple from `RecvDgram::into_parts` and instead return a struct whose components can be extracted by field name.
I think it is. |
CI failure is caused by rust-lang/rust#55376. |
@kpp, @tobz, @carllerche: Is there anything else I should address? |
@twittner Nope, I think this is good. Unfortunately, with failing checks, only @carllerche has the power to merge it. I'll try and ping him to get it merged. 👍 |
@tobz: CI was successful. Maybe you can merge this now? |
All set! 👍 |
Add
methodsRecvDgram::into_inner
andRecvDgram::into_parts
to allow deconstructing aRecvDgram
future in case it can not be driven to completion.Motivation
If the
RecvDgram
future can not be driven to completion, it may become necessary to get back theUdpSocket
and buffer, which is currently not possible. Since UDP is unreliable, it is advisable to use timeouts when receiving datagrams. After a timeout, one would probably retry sending and receiving, which requires the socket, however since it cannot be pulled out ofRecvDgram
again,RecvDgram
is virtually impossible to use together with timeouts.Solution
With
into_inner
andinto_parts
the socket and buffer can be retrieved by consuming the future. This allows to continue using those values.