Ktor Netty Engine: Server vs Client EventLoopGroup Sharing Decision

When a Ktor application hosts both an HTTP server and a client using the Netty engine, the default configuration creates separate EventLoopGroup instances for each pipeline. This can lead to thread overhead or contention under high concurrency, yet the framework does not expose a straightforward API to enforce sharing of a single group across both engines.

The primary goal is to measure whether the current default behavior introduces a measurable bottleneck before applying any optimizations. Understanding the trade‑offs between isolated and shared event loops is essential for resource‑efficient deployment.

Given this uncertainty, the following questions remain:

1. Does Ktor provide any mechanism to automatically detect an existing EventLoopGroup and reuse it for both server and client engines?
2. What are the performance and thread‑safety implications of forcing a shared EventLoopGroup across multiple Netty engines within the same JVM?
3. Is there a recommended pattern or configuration option for sharing an EventLoopGroup that balances resource usage and latency?