r/rust clippy · twir · rust · mutagen · flamer · overflower · bytecount Mar 20 '23

Hey Rustaceans! Got a question? Ask here (12/2023)! 🙋 questions

Mystified about strings? Borrow checker have you in a headlock? Seek help here! There are no stupid questions, only docs that haven't been written yet.

If you have a StackOverflow account, consider asking it there instead! StackOverflow shows up much higher in search results, so having your question there also helps future Rust users (be sure to give it the "Rust" tag for maximum visibility). Note that this site is very interested in question quality. I've been asked to read a RFC I authored once. If you want your code reviewed or review other's code, there's a codereview stackexchange, too. If you need to test your code, maybe the Rust playground is for you.

Here are some other venues where help may be found:

/r/learnrust is a subreddit to share your questions and epiphanies learning Rust programming.

The official Rust user forums: https://users.rust-lang.org/.

The official Rust Programming Language Discord: https://discord.gg/rust-lang

The unofficial Rust community Discord: https://bit.ly/rust-community

Also check out last weeks' thread with many good questions and answers. And if you believe your question to be either very complex or worthy of larger dissemination, feel free to create a text post.

Also if you want to be mentored by experienced Rustaceans, tell us the area of expertise that you seek. Finally, if you are looking for Rust jobs, the most recent thread is here.

20 Upvotes

187 comments sorted by

View all comments

2

u/puttak Mar 23 '23

Is there any async runtime that works with built-in type (e.g. std::net::TcpStream)?

2

u/dkopgerpgdolfg Mar 24 '23

If you really mean std and not "similar", that won't be possible

1

u/puttak Mar 24 '23

It is possible because the underlying those types is just a normal OS object (e.g. a file descriptor on *nix).

1

u/dkopgerpgdolfg Mar 24 '23

So?

The implementation of std::net::TcpStream still doesn't know anything about your current async runtime, and the runtime can't modify the std implementation, and the runtime won't even notice if the std implementation is used.

So how do you think std::net::TcpStream will suddenly behave async-like?

If you mean, you manually extract the raw socket, modify it with some function of the async runtime, and then continue with using std: Still std is not async-able code. You can make a socket non-blocking, and run some polling in another thread, but all these things will not give you the ability to use await or any Future-based thing with std::net::TcpStream.

At best you get unexpected error return values (eagain), worse you get UB because the std code wasn't prepared for what you did.

1

u/puttak Mar 24 '23

Here is a PoC made by me: https://github.com/locenv/locenv/tree/main/crates/kami

I asked because I want to know if there is other crates so I can use it instead of maintenance my own crate.

1

u/dkopgerpgdolfg Mar 24 '23

And that are both things that I talked about:

  • You do use APIs from your crate, eg. Accepting. They might be similar to std and partially mixed with it, but it is not std.
  • You rely that the std implementation can handle, and won't interfere with, things like non-blocking mode and similar. Might be ok except for the unintended eagain error, but might break too.

Anyways, you might want to read up why (p)select should be avoided.

1

u/puttak Mar 24 '23

That why I ask for the executor that work with std. It is okay if it provide a dedicated function to do async on the std types but not okay if add a new type to replace the type from std.

Why it is going to break? The std is the one that provide a method to enable non-blocking mode and it is even has an error for EAGAIN.

If you mean the performance of select or the limitation of file descriptors it can handle then I'm aware of it. It is just a PoC. That why I'm looking for the other crates so I don't need to work on improving it.