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.