News for hackers. Stuff that matters.
Re:Comparison of Rust async and Linux thread context switch ... by baby on Friday February 12, 2021 @06:17AM (#26112451)
That is until you get a weird error or try to do something more complicated.
Re:Comparison of Rust async and Linux thread context switch ... by pas on Friday February 12, 2021 @07:42AM (#26113014)
This is perfectly valid for NodeJS, Python (async and/or threads, hello GIL[0]), and a host of other languages/runtimes.

Also I agree that multi-threaded Rust is probably the best alternative to async Rust.

[0] I have no problems with the GIL, but it's yet another factor to consider when a python multi-threaded program stops working as intended

Re:Comparison of Rust async and Linux thread context switch ... by EugeneOZ on Friday February 12, 2021 @09:19AM (#26113868)
Not sure how you can compare then. You can’t do with the threads what you can do with async functions.
Re:Comparison of Rust async and Linux thread context switch ... by pas on Saturday February 13, 2021 @01:04PM (#26125304)
?

You can do exactly the same thing, after all async is just a big auto-generated state-machine that puts jobs onto a thread pool and waits for them.

Nginx is hand crafted (artisanal!) event-driven C, which is exactly how async runtimes also work. A big loop (the event loop, usually an infinite `while` blocked on epoll()). For example NodeJS uses libuv for this.

The big advantage of first class async support is that we don't have to do this by hand. Plus it makes some optimizations easier (eg. putting things on the stack instead of assigning each event handler a slice of some global [heap allocated] structure).

Or maybe I'm simply misunderstanding what you meant. In that case cloud you clarify please?