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

Expose the async_io function on socket/streams just like try_io #5417

Closed
diondokter opened this issue Jan 31, 2023 · 4 comments
Closed

Expose the async_io function on socket/streams just like try_io #5417

diondokter opened this issue Jan 31, 2023 · 4 comments
Labels
A-tokio Area: The main tokio crate C-feature-request Category: A feature request. M-net Module: tokio/net

Comments

@diondokter
Copy link

Is your feature request related to a problem? Please describe.
I'm working on an async PTP network stack in Rust. I need to ask the kernel for timestamp information of received UDP packets.
The Tokio API doesn't support that directly, but I can make my own syscalls. I need to do that in an async fashion though.

Describe the solution you'd like
Internally, all async UDP socket APIs use the internal self.io.registration().async_io() function to do their syscalls efficiently.
I'd like to get access to that from the outside as well so I can plug in my own syscalls.

This has been done before with the very similar try_io function.

Describe alternatives you've considered
Initially I awaited the readable function on the UDP socket after which I made the syscall: here
However, that just always returns immediately. I think that's because the event isn't cleared because I was making my own syscall and didn't use one of Tokio's APIs.

The only alternative I can see is to simply do the syscall in a loop until it returns ok and just do a millisecond of sleep when it returns WouldBlock. But this is obviously not very elegant.

Additional context
I have already made a PR #5416 for the UDP socket before I realized that the try_io function was defined on more types than just the UDP socket.
If I get the go-ahead on this issue, I can update the PR so the async_io function is present for all types that already implement try_io.

@diondokter diondokter added A-tokio Area: The main tokio crate C-feature-request Category: A feature request. labels Jan 31, 2023
@Darksonn Darksonn added the M-net Module: tokio/net label Jan 31, 2023
@Darksonn
Copy link
Contributor

Initially I awaited the readable function on the UDP socket after which I made the syscall: here
However, that just always returns immediately. I think that's because the event isn't cleared because I was making my own syscall and didn't use one of Tokio's APIs.

If you combine readable with try_io, then the readiness should be cleared properly.

@diondokter
Copy link
Author

diondokter commented Jan 31, 2023

If you combine readable with try_io, then the readiness should be cleared properly.

Ah yes of course. I've tested your suggestion and that works!

Personally I'd still like having an async_io function because that'd turn this code:

loop {
    self.tc_socket.readable().await?;
    match self.tc_socket.try_io(Interest::READABLE, || {
        Self::try_recv_message_with_timestamp(
            &self.tc_socket,
            &self.clock,
            self.hardware_timestamping,
        )
    }) {
        Ok(packet) => break Ok(packet),
        Err(e) if e.kind() == ErrorKind::WouldBlock => continue,
        Err(e) => break Err(e),
    }
}

into this:

self.tc_socket.async_io(Interest::READABLE, || Self::try_recv_message_with_timestamp(
    &self.tc_socket,
    &self.clock,
    self.hardware_timestamping,
)).await

@folkertdev
Copy link
Contributor

#4885 describes a similar problem, but proposes a slightly different solution

@satakuma
Copy link
Member

Closing as async_io has been exposed in #5512.

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-feature-request Category: A feature request. M-net Module: tokio/net
Projects
None yet
Development

No branches or pull requests

4 participants