5 ms·
Its solving the function colouring issue. Your code can run against old-school OS-threads with blocking I/O, or it can run against virtual threads with non-bloc
by MrBuddyCasino 4y ago
Its solving the function colouring issue. Your code can run against old-school OS-threads with blocking I/O, or it can run against virtual threads with non-blocking I/O that look and behave almost exactly the same, but are multiplexed onto fewer underlying OS threads, without needing to introduce language constructs such as async/await or changing anything in your program code except maybe the executor implementation.
Golang is opinionated towards its single coroutine model, there is no way to switch. Its a good model and it works well, but there are cases where it leaks, such as low-performance C interop.
Green threads usually refer to single-threaded runtimes such as Node.
- butt__hugger 4y ago[dead]
- Yoric 4y agoSo it's basically an implementation of transparent of M:N scheduling, right? I remember that early versions of Rust had that but dropped it because building a single implementation of that that scales to all platforms is hard (tm).
- nu11ptr 4y agoYep, M:N cooperatively scheduled. It also requires a "runtime" which Rust didn't want to have
- ithrow 4y agoGreen threads usually refer to single-threaded runtimes such as Node. This doesn't sound right. How is the single-threaded event-loop of node green threads?
- MrBuddyCasino 4y agoYou're right, that was a bad example.
- samus 4y agoApart from that, it makes a lot of sense to have multiple threads in Node. They just run in the background, do stuff, and send events into JS land from time to time.