Re: Capy Review

On Thu, Jun 25, 2026, at 3:11 PM, Vinnie Falco via Boost wrote:
> 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.
[...]
>
> Capy's invariant, stated plainly above, is the coroutine-native 
> expression
> of the same invariant which Boost.Asio's execution model maintains. 
> Asio's
> normative requirement, from
> https://www.boost.org/doc/libs/latest/doc/html/boost_asio/reference/asynchronous_operations.html
> :
>
>     The completion handler shall be submitted for execution as if by
> performing dispatch(ex2, std::move(f)).

I do not think that the stated requirements on a completion handler imply the Capy simple invariant as stated plainly.

There's *lots* of code out in the wild absolutely relying on the executor being switched from the one returned by `co_await asio::this_coro::executor`: https://godbolt.org/z/r17Kxbrdr which exceed Godbolt limits, but prints:

T:01 main enter
T:01 now coro on ctxA executor
T:02 now on ctxB executor and strand
T:01 now back on ctxA
T:01 main exit

> "Capy vs the entire world of C++ coroutine code" is actually "Capy
> continues 24 years of proven Boost design, while the rest of the coroutine
> world chose the path of least resistance."

Looking at the above it would appear Asio has considerably *more flexible* executor semantics around coros.

(Side note, I'm not reviewing Capy at this time, just responding to the email I quoted)

Regards,
Seth
_______________________________________________
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/LF3W4A3DW6RIV5K4QXQMEDYY2J6PNQSV/