discussion: io_context and signal handling at the Capy level #414

From the review result:

From my professional experience writing servers purely with coroutines the io_context is the key to making signals, networking, file-io all go together smoothly. As such it seems like that fundamental construct should be in Capy. [...] Overall handling signals in a coroutine server is pretty essential and seems to be roll-your-own awkward for Capy. [...] I'm unsure if this means Corosio's io_context should be redesigned and moved or if Capy should just have an independent facility. Of course feel free to explain why this isn't needed at all.

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

Current position: Capy contains no OS-facing code; signals and the io_context live in Corosio, and the "Why Capy Is Separate" design page documents the layering. Useful signal handling cannot be written in portable C++: delivering a signal safely into running coroutines requires waking the demultiplexer from an async-signal-safe context (self-pipe, signalfd, kqueue EVFILT_SIGNAL, Windows console handlers), which is machinery only an io_context has.

What this issue should settle:

• Whether the answer to the review is "explain why this isn't needed" (extend the separation page to cover the pure-Capy command-line-tool use case, including what quitter + async_waker can and cannot do without Corosio)
• Or whether Capy grows a portable suspension-point facility that a user-provided signal thread can drive (the async_waker pattern), documented as the sanctioned approach
• Or whether any part of Corosio's io_context should move down