3 ms·

One of the more widely deployed ones is Go. Code looks like with synchronous IO, but everything runs in green threads that can be suspended when IO would block.

One of the more widely deployed ones is Go. Code looks like with synchronous IO, but everything runs in green threads that can be suspended when IO would block. So if you do a File.Read, after it returns, you might be running on a different OS thread because you were suspended mid-Read and later woken up on a different thread. It's generally nice to work with, unless you need to interface with a non-Go library that expects you to use a single thread throughout (e.g. for callbacks), in which case suddenly everything turns into a royal mess.

pansa2 6y ago
> everything runs in green threads that can be suspended when IO would block AFAIK the main objection to this model is that you have to write your code so that it can handle being suspended at any point. OTOH when using async-await, the only potential suspension points are the places marked with `await`.
- gpderetta 6y ago
  I don't think that's a very strong guarantee though. Trivially you can call any function that can block. Less trivially, any function that you can can resume any other suspended coroutine. So in practice there isn't much you can rely on. In general you can not rely on state that has escaped your function to be unmodified across function calls (although here of course rust has tools to prevent that, but they would work even without the sync/async distinction). It is true that other code can only run at function call boundaries, but that's true for any cooperatively scheduled runtime, even with stackfull coroutines.
- tedmielczarek 6y ago
  Rust was originally built with green threads. The RFC that proposed removing them has an extremely detailed explanation of why the change was made pre-1.0: https://github.com/rust-lang/rfcs/blob/0806be4f282144cfcd55b1d20284b43f87cbe1c6/text/0230-remove-runtime.md https://github.com/rust-lang/rfcs/blob/0806be4f282144cfcd55b... I think this has proven itself to be the right decision. It's one of the main reasons that Rust works so well alongside other languages—there's very little default Rust runtime that complicates interop. There are also lots of programming scenarios for which green threads are not the right tool, and Rust accommodates those.

pansa2 6y ago

> everything runs in green threads that can be suspended when IO would block AFAIK the main objection to this model is that you have to write your code so that it can handle being suspended at any point. OTOH when using async-await, the only potential suspension points are the places marked with `await`.

gpderetta 6y ago
I don't think that's a very strong guarantee though. Trivially you can call any function that can block. Less trivially, any function that you can can resume any other suspended coroutine. So in practice there isn't much you can rely on. In general you can not rely on state that has escaped your function to be unmodified across function calls (although here of course rust has tools to prevent that, but they would work even without the sync/async distinction). It is true that other code can only run at function call boundaries, but that's true for any cooperatively scheduled runtime, even with stackfull coroutines.
tedmielczarek 6y ago
Rust was originally built with green threads. The RFC that proposed removing them has an extremely detailed explanation of why the change was made pre-1.0: https://github.com/rust-lang/rfcs/blob/0806be4f282144cfcd55b1d20284b43f87cbe1c6/text/0230-remove-runtime.md https://github.com/rust-lang/rfcs/blob/0806be4f282144cfcd55b... I think this has proven itself to be the right decision. It's one of the main reasons that Rust works so well alongside other languages—there's very little default Rust runtime that complicates interop. There are also lots of programming scenarios for which green threads are not the right tool, and Rust accommodates those.