concurrency-in-scala-with-ce | concurrent programming in Scala , based on the Cats Effect | Functional Programming library

From this tutorial https://github.com/slouc/concurrency-in-scala-with-ce#threading async operations are divided into 3 groups and require significantly different thread pools to run on:

Non-blocking asynchronous operations:

Bounded pool with a very low number of threads (maybe even just one), with a very high priority. These threads will basically just sit idle most of the time and keep polling whether there is a new async IO notification. Time that these threads spend processing a request directly maps into application latency, so it's very important that no other work gets done in this pool apart from receiving notifications and forwarding them to the rest of the application. Bounded pool with a very low number of threads (maybe even just one), with a very high priority. These threads will basically just sit idle most of the time and keep polling whether there is a new async IO notification. Time that these threads spend processing a request directly maps into application latency, so it's very important that no other work gets done in this pool apart from receiving notifications and forwarding them to the rest of the application.

Blocking asynchronous operations:

Unbounded cached pool. Unbounded because blocking operation can (and will) block a thread for some time, and we want to be able to serve other I/O requests in the meantime. Cached because we could run out of memory by creating too many threads, so it’s important to reuse existing threads.

CPU-heavy operations:

Fixed pool in which number of threads equals the number of CPU cores. This is pretty straightforward. Back in the day the "golden rule" was number of threads = number of CPU cores + 1, but "+1" was coming from the fact that one extra thread was always reserved for I/O (as explained above, we now have separate pools for that).

In my Cats Effect application, I use Scala Future-based ReactiveMongo lib to access MongoDB, which does NOT block threads when talking with MongoDB, e.g. performs non-blocking IO.

It needs execution context. Cats effect provides default execution context IOApp.executionContext

My question is: which execution context should I use for non-blocking io?

IOApp.executionContext?

But, from IOApp.executionContext documemntation:

Provides a default ExecutionContext for the app.

The default on top of the JVM is lazily constructed as a fixed thread pool based on the number available of available CPUs (see PoolUtils).

Seems like this execution context falls into 3rd group I listed above - CPU-heavy operations (Fixed pool in which number of threads equals the number of CPU cores.), and it makes me think that IOApp.executionContext is not a good candidate for non-blocking IO.

Am I right and should I create a separate context with a fixed thread pool (1 or 2 threads) for non-blocking IO (so it will fall into the first group I listed above - Non-blocking asynchronous operations: Bounded pool with a very low number of threads (maybe even just one), with a very high priority.)?

Or is IOApp.executionContext designed for both CPU-bound and Non-Blocking IO operations?

The function I use to convert Scala Future to F and excepts execution context: