3 ms·
You would have the same problem in Rust/Tokio and many other languages. The compiler is not able to know which calls could block. Suppose you have this async st
by zelly 6y ago
You would have the same problem in Rust/Tokio and many other languages. The compiler is not able to know which calls could block. Suppose you have this async state machine server on a single thread, super fast, but somewhere it opens a file synchronously, let's say on a network mount to make things worse. No way a purely static VM-free language can help against that. Go (see: goroutines) is able to automatically suspend at those points and continue execution elsewhere. It comes with a big runtime but you get what you pay for.
- heftig 6y agoWhat's Go going to do if some ffi library written in C does a synchronous syscall? It's in the same situation.
- zelly 6y agoGo discourages C FFI but it runs those in kernel threads just to be safe. If you are using a lot of C FFI calls that all block, then it could be a problem (all cores are blocked).
- _-___________-_ 6y agoYes, but there’s nothing akin to the GIL in Rust/Tokio, so the potential impact of blocking is lower, and you can use spawn_blocking to move any blocking code (that you cannot eliminate) off the main worker threads that are polling futures, or use other techniques like run the blocking work on another standard thread and await on a channel for the result.