Re: [Capy/Corosio review] Benchmark results
Vinnie Falco via Boost <[email protected]> Mon, 29 Jun 2026 07:56:10 -0700
| Newsgroups | gmane.comp.lib.boost.devel |
|---|---|
| Message-ID | <CA+EzHGcjqnxAkAwSE4JjskU1OOF2K8zzwAA=KnZxu8oBXtiXyQ@mail.gmail.com> |
On Mon, Jun 29, 2026 at 7:50 AM Ruben Perez <[email protected]> wrote: > 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 Hmm... no, I don't think this is a good idea at all. > 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. > Well, of course the ergonomics are better. Because the Capy timer operations hide a memory allocation through use of std::function: https://github.com/cppalliance/capy/blob/9144290189fa149b27617c7d9a476c8fbffb7b8c/src/ex/detail/timer_service.cpp#L33 Corosio makes this explicit by requiring the user to manage the timer object's lifetime. > 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. > I think these two functions and the timer service should be removed as a condition of acceptance. They can be moved to the examples. Thanks _______________________________________________ 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/7SU3HOWGGMOPJIAZYNVTU3FAYMZIIDVV/