3 Key Themes in the Discussion
1. ClickHouse moving to a dedicated async‑I/O library to bypass thread‑per‑connection limits
"Looks really interesting. I assume this suggests that ClickHouse is going to gradually switch to using this library for network and I/O, thus addressing the main weakness (in my mind) of C++ thread‑per‑connection servers, which is, they (surprisingly!) create too many threads and can't really handle more than, say, a thousand active connections at the same time." — nasretdinov
2. Comparison with existing async runtimes such as SeaStar
"Is this comparable to Sea star [0]?" — jeffreygoesto
3. Interest in lightweight fork/join or continuation‑stealing runtimes and exception‑safety concerns > "It’s narrower than Silk/SeaStar: continuation stealing for CPU‑bound recursive code, not a general async I/O fiber runtime." — enduku
"Seems not exception safe when task switching during unwind." — feverzsj