Async-std: an async port of the Rust standard library
1–10 of 238 posts
Re: Async-std: an async port of the Rust standard library
#2There is further discussion about this library on the rust subreddit: https://www.reddit.com/r/rust/comments/cr85pp/announcing_asy...
Re: Async-std: an async port of the Rust standard library
#3In case anyone else was curious how you create nonblocking file I/O, it appears to use threads.
I am curious if the number of threads is unbounded, or if they have a bounded set but accept deadlocks, or if there is a third option other than those two that I am unaware of.
Re: Async-std: an async port of the Rust standard library
#4Great library, well done. In case anyone was wondering this is not a [no_std] crate even though it can be used as a replacement for std library calls. I guess it (obviously) can't be since it interfaces with the operating system so much.
Re: Async-std: an async port of the Rust standard library
#5This remind me of the blog post "What Color is Your Function?"[0], they had to create a different library that is the same as the standard library but with async functions.
I thought Rust had other, better ways to create non-blocking code so I don't understand why to use async instead.
[0] https://journal.stuffwithstuff.com/2015/02/01/what-color-is-...
Re: Async-std: an async port of the Rust standard library
#6In case anyone else was curious how you create nonblocking file I/O, it appears to use threads. I am curious if the number of threads is unbounded, or if they have a bounded set but accept deadlocks, or if there is a third option other than those two that I am unaware of.
io_uring grew support for buffered IO in recent kernels, so we should have widespread support for this in userspace circa 2025
Re: Async-std: an async port of the Rust standard library
#7In case anyone else was curious how you create nonblocking file I/O, it appears to use threads. I am curious if the number of threads is unbounded, or if they have a bounded set but accept deadlocks, or if there is a third option other than those two that I am unaware of.
Non-blocking I/O via threads? That’s what we used to call blocking I/O :D
Re: Async-std: an async port of the Rust standard library
#8This remind me of the blog post "What Color is Your Function?"[0], they had to create a different library that is the same as the standard library but with async functions. I thought Rust had other, better ways to create non-blocking code so I don't understand why to use async instead. [0] https://journal.stuffwithstuff.com/2015/02/01/what-color-is-...
The caller of the function knows nothing about what happens within the body of the function. (Is it just doing computation, or is it doing I/O?). The async keyword is how the author of the function makes it explicit that caller should choose when to await the result.
Isn't the alternative WCiYF is proposing to allow the caller to treat any function asynchronously, while having no way to discern whether doing so might be counterproductive?
Re: Async-std: an async port of the Rust standard library
#9In case anyone else was curious how you create nonblocking file I/O, it appears to use threads. I am curious if the number of threads is unbounded, or if they have a bounded set but accept deadlocks, or if there is a third option other than those two that I am unaware of.
Are those really the only options? I'm trying to wrap my head around how using a fixed size thread pool for I/O automatically implies deadlocks but I just can't. Unless the threads block on completion until their results are consumed instead of just notifying and then taking the next task..
I can definitely imagine blocking happening while waiting for a worker to be available, though. Did you mean simply blocking instead of deadlock?
Re: Async-std: an async port of the Rust standard library
#10In case anyone else was curious how you create nonblocking file I/O, it appears to use threads. I am curious if the number of threads is unbounded, or if they have a bounded set but accept deadlocks, or if there is a third option other than those two that I am unaware of.
io_uring grew support for buffered IO in recent kernels, so we should have widespread support for this in userspace circa 2025
Or just detect it and swap out the implementation. Less than a year until an Ubuntu LTS that has it.