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 read_with & similar #1040

Open
chrysn opened this issue Sep 28, 2022 · 4 comments
Open

Expose read_with & similar #1040

chrysn opened this issue Sep 28, 2022 · 4 comments

Comments

@chrysn
Copy link

chrysn commented Sep 28, 2022

On an async_std::net::UdpSocket I occasionally need to recvmsg. This is not exposed by async_std, and would barely be a reasonable request, given that std doesn't expose it either.

It is well available through nix (where it is placed well), but accessing it through brings the need to get informed on a read. A naive approach would be asking for access to the watcher -- then it'd be straightforward to do socket.watcher.read_with(|s| nix::...::recvmsg(s.as_raw_fd(), ...).await, but that was amply discussed in #293 and found not to be a good idea.

There was the idea around to expose only .watcher.read_with() as an own .read_with(), which would be more independent of the underlying implementation (it would be trivial with the watcher being as it is, and not expose any types, and at worst would need more than the one-line pass-on that it is now).

Please consider exposing some version of .read_with() (and probably .write_with() and their _mut variants for completeness).

I've tried working around this limitation by creating an own watcher (async_io::async::new(socket.as_raw_fd())), but that would register the same file descriptor twice in the epoll, dying with -EEXIST.

@notgull
Copy link
Contributor

notgull commented Sep 28, 2022

My understanding is that those APIs are intentionally not exposed in this library. If you need lower level access you should use async-io directly.

@chrysn
Copy link
Author

chrysn commented Sep 29, 2022 via email

@chrysn
Copy link
Author

chrysn commented Sep 29, 2022

If it is really once-manual-all-manual (which is understandable from a maintainability point of view), it might be an option to allow getting an OwnedFd out of a socket -- that's an operation the standard library has introduced recently, and would allow doing setup (binding) through async_std and then take it from there. Right now that seems impossible, because while I can get the raw_fd, either I'd drop the original socket (which closes it altogether) or I don't (in which case the file descriptor stays registered for polling and can't be registered again by putting it into an async_io:":Async<>). If that's a way forward, I'd open a request (possibly PR) for conversion to an OwnedFd, which can be trivially implemented by .watcher.into_inner().

@chrysn
Copy link
Author

chrysn commented Jan 23, 2023

As the branch that triggered this is approaching completion, I'd like to ping here about how to progress.

A resolution of "if you need low-level, it must be created low-level" is workable, but would IMO encourage code copy-pasting, and is below what the standard library provides (there, you can open a socket and obtain an OwnedFd). If adding API to turn an opened async-std socket into an OwnedFd (deregistering it from the main loop but keeping the socket open), my offer to provide a PR for that is still good (but I'd prefer to start digging into that only if there is some vague uncommitted positive outlook for it).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants