I have a library (reactor-rabbitmq) that requires ...

# coroutines

[maxmello]

I have a library (reactor-rabbitmq) that requires code to run on some form of thread pool (more specifically, I am able to pass in an java.util.concurrent.Executor that the library then uses for async executions.
The most commonly used implementation for providing this is called Schedulers.boundedElastic() with the following documentation: a Scheduler that dynamically creates a bounded number of ExecutorService-based Workers, reusing them once the Workers have been shut down. The underlying daemon threads can be evicted if idle for more than 60 seconds. The maximum number of created threads is bounded by a cap (by default ten times the number of available CPU cores, see DEFAULT_BOUNDED_ELASTIC_SIZE)

Is it better to use this implementation, or make use of <http://Dispatchers.IO|Dispatchers.IO>.asExecutor() ? I would assume it is better to use the IO Dispatcher, because it already takes into account the number of cores etc, and not using it would basically result in too many actual threads used by the application? (This in in the context of dockerized Ktor services)

[xoangon]

I would say that you either use Dispatchers.Default.asExecutor() or <http://Dispatchers.IO|Dispatchers.IO>.asExecutor() depending on the operations that you are performing. Both of them use a pool of threads that takes into account the available resources of the device, but the first is more performant for intensive computing operations