On Friday, June 26th, 2026 at 12:59 AM, Andrzej Krzemienski via Boost <boost@lists.boost.org> wrote:
czw., 25 cze 2026 o 15:12 Vinnie Falco via Boost <boost@lists.boost.org> napisał(a):
On Thu, Jun 25, 2026 at 4:56 AM Rainer Deyke via Boost < boost@lists.boost.org> wrote:
Pretty sure that's not actually true.
Capy provides an execution model for coroutines which offers one simple invariant:
A coroutine will always be resumed by the same Executor object which was used to launch it.
This should probably be stated in the Capy docs up front.
Along with *why* this guarantee is important and worth trading other things for.
Regards, &rzej;
From my perspective the answer is a combination of ergonomics and correctness. Why do we care about running on a certain executor? A few examples: thread-safety in I/O, a GUI library in which updates must happen on the main thread, you are doing heavy computation on a certain NUMA core and switching would tank your performance. Now imagine you're writing ergonomic coroutines, some algorithm co_awaiting other coroutines. It is a logical unit of work. Maybe you're reading off the network and need to post work to your NUMA core. In Capy, there are no surprises. As you co_await different coroutines your executor propagates and *where* you run is implicit. In the cases where your job is to listen to the network and dispatch work to a thread_pool or maybe a NUMA executor, you explicitly do that with run(different_executor). Without this invariant, it is still possible to make a correct program -- of course. It is just tedious and error-prone. Capy makes it correct by default, it will just do the right thing. Now about trade-offs. There may be cases where you don't require a continuation to "hop back" in order to be correct -- but it will in Capy. Hopping executor adds overhead. You cannot symmetric transfer and you must post. This is a reasonable trade-off in my opinion.