Co-routines?

Posted Jul 12, 2025 23:04 UTC (Sat) by jreiser (subscriber, #11027)
Parent article: SFrame-based stack unwinding for the kernel

I do not see any support for co-routines: a RETURN is replaced by a co-CALL of some other routine in the nest, and is itself the destination of a co-CALL. Incremental producer-consumer bit packing can be expressed as a nest of two co-routines; "the stack" remembers two "leaf" activations, whose co-RETURN (co-CALL) points each vary.

Co-routines?

Posted Jul 14, 2025 7:44 UTC (Mon) by taladar (subscriber, #68407) [Link]

More generally anything using continuation passing style does not really play well with stack traces and won't work with this either without some special considerations.

Co-routines?

Posted Jul 14, 2025 14:22 UTC (Mon) by willy (subscriber, #9762) [Link] (1 responses)

What would you want a "stack trace" to say for coroutines? They may have called each other millions of times by the time we try to "inspect the stack". Surely you wouldn't want to have millions of repetitions of "producer called consumer called producer called ...". Isn't it enough to know "thread is in producer which was called from event loop"?

Is there any prior work in this area we can steal^W benefit from?

Co-routines?

Posted Jul 14, 2025 21:40 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link]

> Isn't it enough to know "thread is in producer which was called from event loop"?

Not really. In particular, this makes debugging the coroutine-heavy code a pure nightmare. Debugger becomes worse than useless.

What I'd love is to have a weak link to the "caller frame". It's OK for it to be garbage-collected if the chain becomes too long.