this post was submitted on 02 Jan 2024
392 points (98.5% liked)
Technology
58303 readers
10 users here now
This is a most excellent place for technology news and articles.
Our Rules
- Follow the lemmy.world rules.
- Only tech related content.
- Be excellent to each another!
- Mod approved content bots can post up to 10 articles per day.
- Threads asking for personal tech support may be deleted.
- Politics threads may be removed.
- No memes allowed as posts, OK to post as comments.
- Only approved bots from the list below, to ask if your bot can be added please contact us.
- Check for duplicates before posting, duplicates may be removed
Approved Bots
founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
Async features in almost all popular languages are a single thread running an event loop (Go being an exception there I believe). Multi threading is still quite difficult to get right if the task isn't trivially parallelizable.
Exactly.
Also every time I've used async stuff, I've pined for proper threads. Continuation spaghetti isn't my bag.
Which language? Usually there's a thread pool where multiple tasks are run in parallel. CPython is a special case due to gil, but we have pypy which has actual parallelism
I've only ever used it in those lua microcontrollers and in Rust with the async keyword.
In lua I doubt they use proper threading due to the GIL. Rust probably can do async with threads, but it just wasn't fun to work with.
Tokio has support for multiple threaded async in rust. As for micro controller, I don't think you can have multiple threads in flight anyways, so that's the best you'll get
Wait, wat? Looking at first sentence. Also async != multi threading.
My goto for easy multi threading is lock free queues. Generate work on one thread and queue it up for another thread to process. Easy message passing and stuff like that. It doesn't solve everything but it can do a lot if you are creative with them. As long as you maintain a single thread ownership of memory and just pass it around the threads via message passing on queues, everything just sorta works out.
Don't use goto.
A lot of languages have an asunc/await facade for tasks run on a background thread for result (c#, clj, py, etc), but it's certainly not the default anywhere, and go most goroutines(?)/other csp implementations are probably going to be yielding for some io most of the time at the bottom anyway
Yes I'm mostly familiar with this in Kotlin. Sometimes this is kinda a footgun because you're writing multi threaded code without explicitly doing so.