Uncertain Thread Allocation in Ktor's CIO Engine for Low‑Traffic Workloads

When deploying a Ktor service that is expected to handle only a handful of concurrent requests, the cost of running the JVM and the underlying engine can be driven largely by how threads are allocated. The CIO engine, designed around coroutines, promises lightweight concurrency, but its internal dispatcher strategy is not fully documented. It is unclear whether a dedicated thread is created for each new connection at startup, even when workerThreads is set to a minimal value.

In contrast, the Netty engine offers explicit workerThreads and maxConnections knobs, yet the switch between epoll and NIO on non‑Linux platforms can change the thread count and memory footprint. Without a clear understanding of these behaviors, a low‑traffic deployment may inadvertently consume more resources than intended, negating the cost‑saving benefits of a minimalist configuration.

What remains unresolved is the exact thread‑allocation policy of the CIO engine under low traffic and whether a single dispatcher can be enforced across all connections. The following questions highlight the gaps that need clarification:

• Does the CIO engine spawn a dedicated thread for each new connection at startup, regardless of the workerThreads setting?
• Is there a documented configuration option to bind all connections to a single coroutine dispatcher, thereby minimizing memory usage?