Second Draft: Coroutines

[Sebastiaan Koppe]

On Thursday, 23 January 2025 at 17:14:50 UTC, Richard (Rikki) 
Andrew Cattermole wrote:
> On 24/01/2025 4:55 AM, Sebastiaan Koppe wrote:
>> I wouldn't dismiss it so easily. For one it explains the 
>> mechanism by which suspended coroutines can get scheduled 
>> again, whereas your DIP only mentioned the `WaitingOn` but 
>> doesn't go into detail how it actually works.
>
> Ahhh ok, you are looking for a statement to the effect of: "A 
> coroutine may only be executed if it is not complete and if it 
> has a dependency for that to be complete or have a value."
>
> The reason it is not in the DIP is because this a library 
> behavior.
>
> On the language side there is no such guarantee, you should be 
> free to execute them repeatedly without error. There could be 
> logic bugs, but the compiler cannot know that this is the case.
>
> About the only time the compiler should prevent you from 
> calling it is if there is no transition to execute (such as it 
> is now complete).

No, that is not what I mean.

Upon yielding a coroutine, say a socket read, you'll want to park 
the coroutine until the socket read has completed. This requires 
a signal on completion of the async operation to the execution 
context to resume the coroutine.

The execution context in this case could be the main thread, a 
pool, etc.

 From that above mentioned C++ link:

> The coroutine is suspended (its coroutine state is populated 
> with local variables and current suspension point).
> awaiter.await_suspend(handle) is called, where handle is the 
> coroutine handle representing the current coroutine. Inside 
> that function, the suspended coroutine state is observable via 
> that handle, and __it's this function's responsibility to 
> schedule it to resume on some executor__, or to be destroyed 
> (returning false counts as scheduling)