On 6/25/26 12:42, Vinnie Falco via Boost wrote:
On Thu, Jun 25, 2026 at 3:12 AM Rainer Deyke via Boost < boost@lists.boost.org> wrote:
The thing about i/o code is that it's never *just* i/o.
...
My choice...was very much deliberate...
Yes, we agree, and this observation supports every Capy decision. That is why the bridges exist. The question is whether crossing the bridge should require explicit action or happen silently. Capy chooses explicit. That's the same choice the type system makes when it won't let you implicitly convert a float to an int.
That makes me wonder why the Capy coroutine is even needed. To run a read_some/write_some loop? I don't believe in i/o loops. For me, i/o is not a loop but a single operation, start to finish. I shouldn't need to wrap a single operation in a coroutine. (Yes, I can see that things are different when streaming through a network connection instead of reading a whole file, or even when streaming a large file from/to disk. But my impression is still that Capy is giving me tools when it could just solve the whole problem.)
That said there is not enough information here to perform a thorough analysis so I will bring back the code from my previous post and ask a question:
capy::task<> f() { co_await my_tmc_task(); }
How do you propose to make this work? Which tmc executor does my_tmc_task run on?
I'm pretty sure it doesn't need any, and will run just fine in the Capy executor if you let it. If it doesn't, that's a problem to bring up to the TMC developers, and not a Capy problem.
OK. This is not clear from the documentation.
You said "do not work correctly." This is not a documentation problem. You observed that the program malfunctioned ("does not work"). What was the actual observed runtime problem?
I did not observe an actual runtime problem. I just assumed that it was not supported, because the documentation gave me that impression. Because if works, then what's the point of the two-call syntax? (Performance benefits, apparently, but that's not explicit in the documentation.)
TMC's advice to just use a better global allocator makes sense
It doesn't make sense for a library whose intent is standardization.
Agreed. It's a band-aid for poorly performing standard library implementations, similar to the recommendation to Boost components over standard components for performance reasons. The real fix would better standard library implementations.
Custom allocators serve many purposes.
Agreed, and I have nothing against then in principle. I just generally expect the use of custom allocators to be an explicit, and possibly quite verbose, user choice. I have no problem with manually passing my allocator around as an argument to all my coroutine functions if that's what it takes. My statement that TMC's advice makes sense was meant to be taken at face value: if the default new/malloc allocator sucks, then perhaps it makes sense to replace it. It was not meant as an argument against custom allocators in general.
If I might go out on a limb here, based on your code examples and your description I would hypothesize that you are coming from a place where you are using TooManyCooks to submit work to its executor, and you saw the Capy/Corosio review and thought to evaluate Capy in the same context of how you are using TMC. The documentation failed you (and that's on us), this left a bad taste in your mouth, everything else is the downstream consequence of the scope mismatch and early friction. Did I understand this wrong?
Actually I started out with Capy, and only went to TooManyCooks when I wasn't able to successfully write my custom IoAwaitable. I actually only found out about TooManyCooks from this page: <https://master.capy.cpp.al/capy/9.design/9o.WhyNotTMC.html> But yes, my initial experience with what turned out to be a documentation problem (that went unfixed for three weeks after being reported) certainly colored my experience. Since many of my complaints turned out to be documentation issues that are now actually being fixed, I expect to revise or withdraw large parts of my review. That said, I do not regret my "documentation first" approach, even if the results were harsh and ultimately misdirected, because that is exactly how end users are going to judge the library: not by what it can do when you know the internals and read the papers, but by what it is documented as being able to do. -- Rainer Deyke - rainerd@eldwood.com