<@U1JP5M6LU> we will make thread pools configurabl...

# ktor

[orangy]

@spand we will make thread pools configurable, but no finite number of threads in a pool will be a silver bullet, and unbounded pool would result in out of memory pretty fast. The problem is that ktor doesn’t know if and which requests will spend a lot of time processing, so it cannot have different “lanes” for fast and slow calls. There several possible solutions to this problem:
– make everything truly async, so that e.g. a database request will not block the thread. It’s hard to do, because JDBC is sync by nature, and there is no other generally accepted API which would be async.
– make a secondary (manually managed) thread pool, that will handle long running requests. This is also an approach in majority libs that claim async DB, which helps a bit, but doesn’t solve the problem entirely. So it makes a separate thread pool for sync long tasks, so that main pool can still process fast requests.
– add a feature to ktor so that you can somehow mark a request as a slow one, and it would offload it to a secondary pool. Given that with Kotlin coroutines it’s as simple as a few lines function, it is pretty much the same as a previous variant.