Multithreading, why does everyone always do it wrong? One of life's big questions.
Redis nailed multithreading :)
Local async executors and why they should be the default
11–20 of 327 posts
Re: Local async executors and why they should be the default
#12Re: Local async executors and why they should be the default
#13> Posted on June 9, 2022
Yeah, it is old. But I only found it recently and did not see a discussion of it yet. I found this quite interesting. I love rust, but async rust always seems almost like a different language. Lifetimes become much more complex and much less useful, you use Box and Arc way too much. It seems like you would be better off if everything was heap allocated. Working with local futures brings back some of the things I love…
> posted on June 9, 2022
> this is old
???
Re: Local async executors and why they should be the default
#14> Yes the RwLock and mpsc comes from Tokio and lets you .await instead of blocking a thread, but these are not async primitives, these are multi-threading synchronization primitives.
The only reason all this async stuff even exists is because we want concurrency. We want to say "while this one task waits for I/O, this other task will do stuff". So it's not too surprising to me that an intro to async would include synchronization primitives. Those primitives aren't really "thread"-specific if by thread you mean OS thread. When you do async like this, you're basically re-implementing OS threads in user space.
Re: Local async executors and why they should be the default
#15While the article mostly focuses on the cognitive cost, which I deeply sympathize with, I do wonder about the runtime performance cost. Are there any good benchmarks actually quantifying the impact of all that extra thread-safety and the hoops that it adds? I'm not asking simply due personal interest in seeing the numbers, but also because if we want to steer the community towards this non-threadsafe direction it would help to have material to back the ideas and I suspect Rust community would be more responsive to complaints about perf than cognitive cost.
Re: Local async executors and why they should be the default
#16"If you write regular synchronous Rust code, unless you have a really good reason, you don't just start with a thread-pool. You write single-threaded code until you find a place where threads can help you, and then you parallelize it, [..]" I cannot agree more with that. As someone who's done a good deal of Java in my day job, I can tell you a thing or two about spawning threads willy-nilly. At least it is easier to…
[deleted]
Re: Local async executors and why they should be the default
#17> Yes the RwLock and mpsc comes from Tokio and lets you .await instead of blocking a thread, but these are not async primitives, these are multi-threading synchronization primitives. The only reason all this async stuff even exists is because we want concurrency. We want to say "while this one task waits for I/O, this other task will do stuff". So it's not too surprising to me that an intro to async would include syn…
Async/await is green threads with better scoping and syntactic sugar.
Which lets be honest, is something green threads desperately needed.
Re: Local async executors and why they should be the default
#18This is bad editorializing. You're putting words in the author's mouth that cannot even be found on that page.
Don't do that.
Edit: Thanks to the mods or whoever fixed it.
Re: Local async executors and why they should be the default
#19reason?
Re: Local async executors and why they should be the default
#20> Yes the RwLock and mpsc comes from Tokio and lets you .await instead of blocking a thread, but these are not async primitives, these are multi-threading synchronization primitives. The only reason all this async stuff even exists is because we want concurrency. We want to say "while this one task waits for I/O, this other task will do stuff". So it's not too surprising to me that an intro to async would include syn…
I think the article's point is that if you're doing single-threaded concurrency then you don't (or at least might not) need synchronization primitives. If you're writing a Node script, for example, then you don't have to worry about two callbacks trying to modify the same variable at the same time because you know that there is only one thread of execution.