Skip to content
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

tokio: Add back poll_* for udp #2981

Merged
merged 5 commits into from Oct 22, 2020
Merged

Conversation

leshow
Copy link
Contributor

@leshow leshow commented Oct 17, 2020

As discussed in #2830 the first step to getting UdpFramed back is the poll functions. I've added these back, following the new style.

I could have just re-enabled UdpFramed on this PR too, but I thought we might take the opportunity to discuss any changes that we may want to make to that. In it's current state it still requires a split-like API to do concurrent send/recv

@Darksonn Darksonn added A-tokio Area: The main tokio crate C-enhancement Category: A PR with an enhancement or bugfix. M-net Module: tokio/net labels Oct 17, 2020
Copy link
Contributor

@Darksonn Darksonn left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These shouldn't be #[doc(hidden)].

@leshow
Copy link
Contributor Author

leshow commented Oct 17, 2020

Cool, I had them as hidden because that's what they used to be, I'll write up some docs for the methods.

The only async method that doesn't have a poll_ version right now is connect. Do we need one?

@leshow leshow force-pushed the add_udp_poll branch 2 times, most recently from e803ced to b260e0c Compare October 17, 2020 17:28
/// This function may encounter any standard I/O error except `WouldBlock`.
///
/// [`connect`]: method@Self::connect
pub fn poll_recv(&self, cx: &mut Context<'_>, buf: &mut [u8]) -> Poll<io::Result<usize>> {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Shouldn't buf be the new ReadBuf here?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good point. Same for poll_recv_from.

Copy link
Contributor Author

@leshow leshow Oct 19, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah okay. For converting ReadBuf -> &mut buf there's a few methods that we could use. initialize_unfilled which is safe and initializes the buffer, and unfilled_mut which is unsafe and assumes it's initialized. Methods in TcpStream use the unsafe version but they are private, if that makes any difference.

edit: why exactly do we want ReadBuf exposed here? UdpSocket doesn't even implement AsyncRead which is where ReadBuf is mainly used/exposed

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well ReadBuf would allow receiving into uninitialized memory. I'm pretty sure the underlying IO primitives should support that. Even if you prefer to write a version that initializes it first, defining it with ReadBuf would be necessary for adding that optimization later without a breaking change.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Alright, updated.

Copy link
Member

@seanmonstar seanmonstar left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My only thought is that we should document that these poll_ methods have a downside of only being able to be associated to one task per read/write direction, as opposed to the async fn methods, which should be preferred if you don't require polling specifically.

@leshow
Copy link
Contributor Author

leshow commented Oct 19, 2020

Right, I remember reading this about TcpStream, I can go back and add that. Does that limitation decrease their use in a possible UdpFramed implementation?

@seanmonstar
Copy link
Member

I don't think it decreases the use there. That's a case where Stream is using the read direction, and Sink the write direction, and you can't use async fn, so the poll functions are correct.

@leshow leshow force-pushed the add_udp_poll branch 2 times, most recently from 8418437 to b2aef3e Compare October 19, 2020 22:28
Copy link
Contributor

@Darksonn Darksonn left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Using the phrasing from Future.

tokio/src/net/udp/socket.rs Outdated Show resolved Hide resolved
@leshow
Copy link
Contributor Author

leshow commented Oct 20, 2020

I was poking around in mio::UdpSocket and noticed it has functions for peek_from that aren't exposed, any problems with adding that to this PR? What about poll_peek?

@Darksonn
Copy link
Contributor

We already have those on TcpStream, so it should be fine. Remember ReadBuf on poll_peek.

tokio/src/net/udp/socket.rs Outdated Show resolved Hide resolved
tokio/src/net/udp/socket.rs Outdated Show resolved Hide resolved
Comment on lines 366 to 370
pub fn poll_recv(
&self,
cx: &mut Context<'_>,
buf: &mut ReadBuf<'_>,
) -> Poll<io::Result<usize>> {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since it uses ReadBuf, it should return Result<()> for consistency with AsyncReadExt::read.

Copy link
Contributor Author

@leshow leshow Oct 21, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was going to reply saying poll_peek on TcpStream returns the size, but I just noticed it also does not use ReadBuf. That's something that's been overlooked, yes? I can add a quick fix there also.

edit: It appears the use of &mut [u8] in TcpStream poll_ is pervasive and may be deserving of it's own PR. Open to suggestions

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, TcpStream::poll_peek was overlooked. See #2987.

tokio/src/net/udp/socket.rs Outdated Show resolved Hide resolved
Copy link
Contributor

@Darksonn Darksonn left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this is ready besides a doc typo.

tokio/src/net/udp/socket.rs Outdated Show resolved Hide resolved
Co-authored-by: Alice Ryhl <alice@ryhl.io>
@carllerche carllerche merged commit 358e4f9 into tokio-rs:master Oct 22, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-tokio Area: The main tokio crate C-enhancement Category: A PR with an enhancement or bugfix. M-net Module: tokio/net
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants