Re: Capy Review

pt., 26 cze 2026 o 15:28 Steve Gerbino via Boost <[email protected]>
napisał(a):

>
> 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.
>

I have been re-reading this reply, and I cannot understand what is being
communicated here.

You mention thread-safety. But when I have a thread-pool executor,
thread-safety still remains my concern.

It looks like you are displaying a use case where three executors are
employed in a single program, and that you are claiming that without the
"continuation on the same executor" guarantee, we would never know which
continuation is executed where. I do not buy it. It would require a lot of
effort from the programmer to create such a situation. The complaint from
Rainer was communicating (If I got that right) is that he wants a
Capy-coroutine (returning a IoAwaitable) to be executed on another
library's executor, with similar  "continuation on the same executor"
guarantee.

I tried to answer the question myself and the best rationalization I came
up with is this.

In order to get the lock-free concurrency-safety via a strand, we have to
have the guarantee that continuations do not "leak" to non-strand executors.

We want a _structured_ usage of coroutines, in the same sense as a for-loop
is more structured than goto's and branches, so that we can more easily
(or, at all) reason about the program execution.

But I do not know if this is the original reason.

Regards,
&rzej;


>
> 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/
>
_______________________________________________
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/GSXINIFAKLQHISKKZNEYIMYHZATDHNXM/