quitter's place in the library

[sgerbino]

From the review result:

Then I found, not in the docs, but in the examples from the repo the 'quitter' example -- pretty much exactly the kind of thing today we'd write using asio. [...] Looking at the code in the quitter example, well I wouldn't have guessed how to write that and the asio code would be more concise. So I think this goes to the heart of the question: why leave this stuff in if it's not really documented?

Source: Boost review result (conditional acceptance), Boost mailing list, September 2026.

The documentation half is already tracked (#409). This issue is the design half: is quitter a supported, recommended part of the toolkit, and if so what is the sanctioned shutdown pattern built on it?

• Keep and promote: document the quitter + signal pattern as the recommended pure-Capy shutdown idiom (depends on the outcome of the io_context/signals discussion)
• Keep as a low-level tool with the example as its documentation
• Remove, if the answer to the review's question is that it should not ship

[akrzemi1]

I remember reading in Slack that quitter was meant to be only "a proof of concept", and never the library component. If this were to be the case, then another alternative would be to put it in the Examples section of the documentation. Then everyone would see how one writes a cancel-propagating IoAwaitable.

But that was the original motivation. Maybe now that it gained some visibility, it deserves the place in the library.

To me, the answer boils down to a design question:

How does Capy want to treat cancellation.

Should we get this automated cancellation, "cancelling an operation implies cancelling enyone co-awaiting on it, unless explicitly opted out.