Re: Capy Review

On Friday, June 26th, 2026 at 12:59 AM, Andrzej Krzemienski via Boost <[email protected]> wrote:

> czw., 25 cze 2026 o 15:12 Vinnie Falco via Boost <[email protected]>
> napisał(a):
> 
> > On Thu, Jun 25, 2026 at 4:56 AM Rainer Deyke via Boost <
> > [email protected]> 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.
_______________________________________________
Boost mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://lists.boost.org/mailman3/lists/boost.lists.boost.org/
Archived at: https://lists.boost.org/archives/list/[email protected]/message/2QIYRBIPOVGVQL6FSUFOI3LIATT52YPU/