| (Edited to fix footnotes) > blocks the current thread of execution That's a green thread.[1] To quote Wikipedia[2]: > a thread of execution is the smallest sequence of programmed instructions that can be managed independently by a scheduler This is the definition the doc is using. The thread of execution that is blocked is a green thread -- the sequence of instructions containing the `await` that is managed by a scheduler managed by Raku. > This stands in direct contradiction to what was said in the thread here: >> so while the code containing the `await` blocks and waits, the underlying thread/core is released > Unless the OP referred to a _different_ await No, what I meant by "underlying thread/core" is an OS thread as against a green thread, and what I meant by "released" wasn't that it was released back to the OS but instead that Raku's scheduling sees the `await`, blocks the enclosing green thread, and immediately unblocks some other green thread by "stealing"[3] the OS thread to run that other green thread instead. I hope I've now reassured you that Raku(do) both eliminates the red/blue distinction and doesn't block OS threads. Yes, it's unusual among PLs. No, it's not easy to design a PL to do this at a language level. Nor is it easy to implement. (For example, the Rakudo implementation involves taking a continuation[4].) But it is possible, and Raku has never had the red/blue distinction, and has had work stealing semantics for `await` since 2018. [1] https://en.wikipedia.org/wiki/Green_threads [2] https://en.wikipedia.org/wiki/Thread_(computing) [3] https://en.wikipedia.org/wiki/Work_stealing [4] http://jnthn.net/papers/2018-concurrency-guts.pdf#page=67 |