[OT] Article on coroutines: Function Colors Represent Different Execution Contexts

[Derek Fawcus]

On Monday, 11 August 2025 at 16:36:32 UTC, Richard (Rikki) Andrew 
Cattermole wrote:
>
> Stackful coroutines have a massive problem associated with 
> them, you cannot model yields. This means things like locks can 
> be held whilst yielding. Leading to deadlocks.

My approach is usually actor or CSP style, and hence avoiding 
explicit yields, and also generally doing within shared 
structures requiring locks.  So it hasn't been an issue.

In a recent program, I had two shared structures needing explicit 
locks, but they were encapsulated within constrained routines, 
sans comms.  Yes it required rigor, rather than the compiler 
proving something.

For CSP style, the obvious way to model the yield is to have 
syntax for the send and receive, as Go does (and Alef did), then 
they could be checked by the compiler (what I assume you mean by 
modelling), to ensure there is no yield while holding the lock.

Since there is already a Go linter doing certain lock checks 
(that a mutex is not copied), possibly it could be enhanced to 
perform the above check - i.e. no (blocking) send or receive 
while holding a lock.

[What I need to ponder is if yielding while having a 
non-premptive coroutine scheduler - i.e. not Go style - would 
necessarily be a problem.  My suspicion is that it wouldn't 
always be a problem, but it would be difficult for the tooling to 
detect and prove that]

[snip]

> Like this?

[snip]

I'll have a think about that and see if I can figure out what 
you're doing.

What was the reference to your DIP again?