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/