Second Draft: Coroutines

[Richard (Rikki) Andrew Cattermole]

On 24/01/2025 9:12 AM, Sebastiaan Koppe wrote:
> 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)

Right, I handle this as part of my scheduler and worker pool.

The language has no knowledge, nor need to know any of this which is why 
it is not in the DIP.

How scheduling works, can only lead to confusion if it is described in a 
language only proposal (I've had Walter attach on to such descriptions 
in the past and was not helpful).