On 29 Jun 2026 17:49, Ruben Perez via Boost wrote:
On Mon, 29 Jun 2026 at 16:41, Vinnie Falco <vinnie.falco@gmail.com> wrote:
On Mon, Jun 29, 2026 at 7:40 AM Ruben Perez via Boost <boost@lists.boost.org> 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...
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.