[raiph]

It's a cooperative yield point so while the code containing the `await` blocks and waits, the underlying thread/core is released and "stolen" by the standard scheduler for other work, and then resumed when the processes it's waiting for complete or are cancelled.

What problem is there beyond that?

[valenterry]

I doubt that this is the case. Before I answer, let me ask you back: Why don't all languages just do it like that? Sounds pretty easy, no?

[raiph]

> Why don't all languages just do it like that?

I think the main problem has been that it requires building an appropriate concurrency design into the foundation of a language.

For most PLs, concurrency is somewhat of an afterthought, and even for those where concurrency was addressed from the get go, the design nevertheless doesn't support work stealing, or, if it does, doesn't support doing so at the language level.

> I doubt...

Scepticism is healthy. :)

But regardless of my speculation about why most PLs don't go this route:

* The general technique (called "work stealing"[0]) was first implemented last century;

* PLs can support it directly at the language level provided they have suitable foundations;

* Raku is one such PL.

The first version of Raku (Raku Christmas, released Christmas Day 2015) already eliminated the need for function colouring. While the first version included an array of concurrency, async, and parallel processing features, including an `await` keyword, there has never been an `async` keyword in Raku. This is unusual, but Raku is not the only recently released PL to do so.

Work stealing semantics for `await` were only formally introduced in Raku Diwali, released Diwali day 2018, and the corresponding Rakudo compiler. Again, this makes Raku unusual, but not unique.

(What is perhaps unique is that Raku programs can include both old and new semantics in the same program. Raku has a radically different take on language evolution and backwards compatibility such that incompatible changes don't mean modules are incompatible with each other. Not easy to do, but possible, as demonstrated by Raku programs that make use of both Christmas and Diwali modules.)

> Sounds pretty easy, no?

It is easy for users. Once it's implemented in a language.

But it's not easy for language designers and implementers. (And it's essentially impossible to introduce if a PL has already adopted older approaches to concurrency.)

[0] https://en.wikipedia.org/wiki/Work_stealing

[bmn__]

It is not okay to continue to sow doubt. I require you taking eight minutes to download the language and validating/disproving the claims.

[valenterry]

That is your opinion. Mine is that it is okay to "sow doubt", similar to that it is okay to "sow doubt" when someone claims they built a perpetuum mobile.

But since you are asking me to download the language so politely: I think this is not necessary. A look in the documentation (https://docs.raku.org/language/concurrency) seems to be enough:

> The subroutine await is almost equivalent to calling result on the promise object returned by start but it will also take a list of promises and return the result of each

So "await" is equivalent to calling "result". What does calling "result" do?

> result blocks the current thread of execution until the promise is kept or broken

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, I would say: case closed.

[raiph]

(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

[lizmat]

Because it is not easy to do. Have you tried it?

[valenterry]

See my other post - it doesn't look as if raku is doing what was claimed in this thread here.

[raiph]

Looks deceive. :)