Re: [Capy/Corosio review] Benchmark results

Andrey Semashev via Boost <[email protected]> Mon, 29 Jun 2026 18:08:57 +0300
Newsgroups gmane.comp.lib.boost.devel
Message-ID <[email protected]>
On 29 Jun 2026 17:49, Ruben Perez via Boost wrote:
> 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.

My general preference is that it is best to avoid spawning internal
threads and instead design API in such a way that the user provides a
thread, if one is needed. This gives the user more control over resource
management and allows for custom thread initialization, which may be
necessary if user's code is supposed to be run in that thread. Think of
stuff like thread custom stack size or CoInitialize().

I'm not sure which library timeouts and delays belong to, but I do agree
that these features should be based on IO reactor loop. IMHO, if Capy
has to provide those features while it doesn't provide IO reactors, it
should accept an externally-provided reactor to implement those features.

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