pt., 26 cze 2026 o 15:28 Steve Gerbino via Boost <boost@lists.boost.org> napisał(a):
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.
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 -- boost@lists.boost.org To unsubscribe send an email to boost-leave@lists.boost.org https://lists.boost.org/mailman3/lists/boost.lists.boost.org/ Archived at: https://lists.boost.org/archives/list/boost@lists.boost.org/message/2QIYRBIP...