Re: [Capy/Corosio review] Benchmark results

On Mon, 29 Jun 2026 at 16:41, Vinnie Falco <[email protected]> wrote:
>
> On Mon, Jun 29, 2026 at 7:40 AM Ruben Perez via Boost <[email protected]> wrote:
>>
>> The extra thread is allocated by the timer service in Capy, underlying capy::delay() and capy::timeout().
>
>
> Huh? How can Capy implement delay() and timeout() without a reactor? I don't think those functions belong in Capy.
>
> Thanks
>

It looks like it can. These functions seem to have been there for a while:

https://master.capy.cpp.al/capy/reference/boost/capy/timeout.html
https://master.capy.cpp.al/capy/reference/boost/capy/delay.html

I asked myself the same question the first time that I saw them :)

Looking into the code, Capy spawns a thread and waits on a
std::condition_variable to implement this:
https://github.com/cppalliance/capy/blob/develop/src/ex/detail/timer_service.cpp

I do agree it's odd, especially considering that Corosio has timers,
and cancel_at/cancal_after members.

I find the ergonomics of delay() and timeout() much better than those
of timers, but that's a different concern to what's being discussed
here.

This makes me wonder if it is safe to use delay() and timeout() with
an io_context with a concurrency_hit of one, or not.
_______________________________________________
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/YELY4OQM4VQZTS3YPT5ZWHGEMQVJDCPL/