Bit weird to have a rust tutorial list JavaScript async as assumed knowledge tbh.
Who Runs Your Rust Future? Hands-On Intro to Async Rust
11–20 of 40 posts
Re: Who Runs Your Rust Future? Hands-On Intro to Async Rust
#12[flagged]
Re: Who Runs Your Rust Future? Hands-On Intro to Async Rust
#13Don't use async but use threads instead. Threading treats the CPU as a resource, which it is! Whereas async simply locks the CPU, which can deplete the system for longer computations. If you hate garbage collection pauses (which most Rust users do) then don't use async.
They are two different models and sometimes one is better than the other. Async tends to win for IO-bound code (due to using less memory for each blocked coroutine) and threads for CPU-bound code.
Re: Who Runs Your Rust Future? Hands-On Intro to Async Rust
#14Don't use async but use threads instead. Threading treats the CPU as a resource, which it is! Whereas async simply locks the CPU, which can deplete the system for longer computations. If you hate garbage collection pauses (which most Rust users do) then don't use async.
The whole point of async/await (besides allowing synchronous style code instead of callbacks) is that it lets you yield the thread efficiently back to the executor (OS threads have a massive overhead in comparison). And if you're doing something that blocks the thread instead of yielding it, you can choose between either spawn_blocking or a thread pool.
Re: Who Runs Your Rust Future? Hands-On Intro to Async Rust
#15Don't use async but use threads instead. Threading treats the CPU as a resource, which it is! Whereas async simply locks the CPU, which can deplete the system for longer computations. If you hate garbage collection pauses (which most Rust users do) then don't use async.
The problem with all these async things is that people don't understand what's actually happening.
It's just doing a loop and a call to poll(), that's it.
It's way way way less expensive than using threads. Of course you must give control to your main loop every once in a while, so if you have a long computation you either create a thread or split it and return control to your main loop.
It's how all GUI programming has always been done.
Re: Who Runs Your Rust Future? Hands-On Intro to Async Rust
#16Don't use async but use threads instead. Threading treats the CPU as a resource, which it is! Whereas async simply locks the CPU, which can deplete the system for longer computations. If you hate garbage collection pauses (which most Rust users do) then don't use async.
Your confusing concurrency with parallelism. Async allows one core to switch between many threads of execution that can do work and not stop one thread of execution because it needs to wait for a resource. It's beneficial to use async if you're application is I/O heavy even if it's single threaded. > Whereas async simply locks the CPUWhereas async simply locks the CPU This is also completely nonsense, context switchi…
> context switching behavior is OS dependent and your average general purpose kernel is not cooperative.
True, but if all you are using is async, then you're basically back at Windows 3.1 cooperative multitasking, except now within a Rust program.
Re: Who Runs Your Rust Future? Hands-On Intro to Async Rust
#17Bit weird to have a rust tutorial list JavaScript async as assumed knowledge tbh.
Yeah, it also makes it seem like Rust is weird for using Future as the type name, but actually JavaScript (Promise) is the odd one out here.
Probably a JS dev learning Rust without much exposure to other languages
Re: Who Runs Your Rust Future? Hands-On Intro to Async Rust
#18Don't use async but use threads instead. Threading treats the CPU as a resource, which it is! Whereas async simply locks the CPU, which can deplete the system for longer computations. If you hate garbage collection pauses (which most Rust users do) then don't use async.
You can mix and match. For work, I run a conferencing server ... packet processing runs in one thread per core, out of band signalling runs in async on a separate pool of threads. It used to all be async, but using threads for packet processing shaved a little cpu, doing my own timers shaved a little cpu, cpu pinning the threads and the sockets shaved a little cpu, and at the end of the day we shaved a couple instances... too bad instance cost is immaterial compared to bandwidth. Also, it probably drives my coworkers crazy ... but there's really only one spot where it causes issues, so eh, it's fine.
For other things, async task (or green thread, whatevs) per connection is a very nice model that you can't do with thread per connection because I don't think OSes are happy to gave hundreds of thousands of threads.
Re: Who Runs Your Rust Future? Hands-On Intro to Async Rust
#19Don't use async but use threads instead. Threading treats the CPU as a resource, which it is! Whereas async simply locks the CPU, which can deplete the system for longer computations. If you hate garbage collection pauses (which most Rust users do) then don't use async.
[dead]
Re: Who Runs Your Rust Future? Hands-On Intro to Async Rust
#20Don't use async but use threads instead. Threading treats the CPU as a resource, which it is! Whereas async simply locks the CPU, which can deplete the system for longer computations. If you hate garbage collection pauses (which most Rust users do) then don't use async.
You use async to preserve system resources. For example you can easily exhaust the host with ~20k connections running a thread-per-connection schema where each thread simply waits for epoll event, async prevents this by having a threadpool of ~16 threads that handle all the connections instead of polling the scheduler wakes it up, asks "do you haev work to do" if not continues to next task. (This heavily varied by th…
> You use async to preserve system resources. For example you can easily exhaust the host with ~20k connections running a thread-per-connection schema...
Sure, if you need to run 20k connections then use async. But the fact of the matter is that the vast majority of software is not going to take on 20k connections. Those people (i.e the majority of software devs) should use threads, because they are much easier to reason about and work with.