On 6/25/26 16:58, Peter Dimov via Boost wrote:
The problem is that there needs to be a standard way to propagate important state to the foreign coroutine, so that the foreign coroutine can at least propagate that same state back to you if it co_awaits one of yours.
That state in Capy consists of the executor, the stop token, and the allocator. And while you can argue that the allocator is optional (but it isn't in practice), the other two most certainly are not.
Let's call this the "A co_awaits B, B co_awaits C" problem, where A and C use the same coroutine library. This is distinct from the "A co_awaits B, B resumes A" problem, where the awaitable B attempts to return control back to A after suspending. This problem has solutions. The verbose, explicit option to carry the auxiliary objects we need as function arguments. I actually like this option for stop tokens. It means that each co_await makes it explicit if the awaitable in question (potentially) uses the stop token or the allocator. It means being able to substitute in a different stop token or allocator at the call point. (To be fair, Capy offers just that functionality for stop tokens, through boost::capy::run.) (Note that even in Capy, stop tokens require manual checking to work. It is entirely possible to write uncancelable coroutines or other IoAwaitables in Capy. And cancellation may not be necessary if a coroutine is fast enough, and guaranteed to stay fast enough. Not accepting a stop token as an argument makes it explicit if this is intentional, and accepting a stop token as an argument makes it less likely to happen unintentionally because the argument is there to remind you.) The pragmatic option is to simply create a new context at the point where C is called. C has a stop token, but it's distinct from A's stop token. If we don't want that, we can manually pass the stop token through B. The nuclear option is to declare our coroutine library non-reentrant. We don't need to allow foreign awaitables to call our awaitables. This is restrictive, but it is less restrictive than not allowing foreign awaitables at all. (Strictly speaking, we don't even need to allow coroutines from our own library to co_await coroutines from the same coroutine library! "co_routines are awaitables" is a convention, not a rule.) -- Rainer Deyke - rainerd@eldwood.com