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

[Derek Fawcus]

On Sunday, 10 August 2025 at 13:49:43 UTC, Richard (Rikki) Andrew 
Cattermole wrote:
> Here is an introductory blog article that attempts to refute 
> the notion that function coloring in coroutines is a bad thing. 
> Which may interest some people.
>
> https://danieltan.weblog.lol/2025/08/function-colors-represent-different-execution-contexts

I'm partway through reading this paper, and it argues in a 
different direction.

https://www.cs.tufts.edu/~nr/cs257/archive/roberto-ierusalimschy/revisiting-coroutines.pdf

Namely for one particular form of stackful coroutine, which they 
term as a "full asymmetric  coroutines".

There are also some well known paper prepared for the C++ WG:

- p1364r0.pdf : Fibers under the magnifying glass
- p0866r0.pdf : Response to "Fibers under the magnifying glass"
- p1520r0.pdf : Response to response to "Fibers under the 
magnifying glass"

 From memory they touch upon an important part of the impact of 
"function colouring".

One of the observations I found in the 866 paper was that a 
stackless coroutine which exceeds the lifetime of its invoker, in 
effect becomes an inefficiently implemented segmented stackful 
couroutine.

The obvious mitigation would then be to only allow such stackless 
corotuines to used in a "structured concurrency" manner, such 
that they can not exceed said lifetime.

--

As to the post you mention, I'm not sure what he is trying to 
suggest by 'execution bridges'. I don't believe he has proven 
that 'function colouring' is a good thing, or at least something 
to be embraced.

Possibly he needs to better expand upon his concept of 'execution 
bridge', as for now I just see it as unhelpful hand waving.


 From a personal perspective, I've used both approaches (stackful 
and stackless), but I tend to view then as having different 
domains of applicability, and I just prefer stackful when I'm 
able to use it, as being easier to reason about.

--

Taking the stackless one, I've only really found it useful in the 
Simon Tatham form, where what is happening is explicit; and at 
most I would desire some light weight method (syntax, or 
whatever) way of achieving that.

However, I've not found the 'async' and 'await' pattern to be 
useful there, as it just ends up exploding the necessary mental 
juggling.  So I don't have a concrete suggestion of how to 
achieve that.

I've actually found the explicit queuing of event based callbacks 
(see Zebra, and FRR) easier to reason about as the parts are in 
one's face. Still there is no 'colouring', only a single 
execution stack, and one still has to manually manage the state 
(usually in shared structures passed between even callbacks).

Blocking is handled/avoided by explicitly queuing a new callback 
event. That sort of scheme generally has a fairly small "runtime" 
to drive the callback events.

So possibly syntax for creating that form of system may be more 
useful than the async/await scheme?  Maybe something which can 
automatically create a closure representing the continuation from 
a completed call to a routine marked as 'blocking', or maybe just 
a 'blocking' / 'async' call site?