UnsafePools
- Authors
Lorand Szakacs, https://github.com/lorandszakacs
- Since
14 Jun 2019
Value members
Concrete methods
Cached pools should be used for blocking i/o. Without very stringent back-pressure and 100% certainty that you never overload with blocking i/o you will almost certainly freeze your application into oblivion by doing blocking i/o on a fixed thread pool.
!!! WARNING !!! Prefer Pools.cached, unless you know what you are doing. The behavior the the Execution context itself is the same for both, but the former is actually safer to use :)
Cached pools should be used for blocking i/o. Without very stringent back-pressure and 100% certainty that you never overload with blocking i/o you will almost certainly freeze your application into oblivion by doing blocking i/o on a fixed thread pool.
- Value Params
- daemons
whether or not the threads in the pool should be daemons or not. see java.lang.Thread#setDaemon(boolean) for the meaning for daemon threads.
- threadNamePrefix
prefixes this name to the ThreadID. This is the name that usually shows up in the logs. It also prefixes "cached" to the names.
This is a reasonable default to back up your application's ContextShift. Make sure that you NEVER do blocking I/O on this thread pool. NEVER! — it's not that hard as long as you respect referential transparency, and are careful with using 3rd party libraries (especially Java ones).
This is a reasonable default to back up your application's ContextShift. Make sure that you NEVER do blocking I/O on this thread pool. NEVER! — it's not that hard as long as you respect referential transparency, and are careful with using 3rd party libraries (especially Java ones).
Additionally, we can't really instantiate one of these in a resource "safe" manner, because we need it for the cats.effect.IOApp.
Instantiates a fixed thread pool with the maximum threads being equal to the number of available processors available to the JVM (N.B., this number can be less than what your hardware offers), and a minimum of two threads in order to, quoting cats-effect:
"lower-bound of 2 to prevent pathological deadlocks on virtual machines"
- Value Params
- threadNamePrefix
prefixes this name to the ThreadID. This is the name that usually shows up in the logs. It also prefixes the total number of threads in the thread pool in the name.
- Returns
A fixed thread pool with at least two fixed threads, or the number of available processors.
The difference between this one and ExecutionContextMainFT is that this one allows to us to have a fixed thread pool with 1 thread.
!!! WARNING !!! Prefer Pools.fixed, unless you know what you are doing. The behavior the the Execution context itself is the same for both, but the former is actually safer to use :)
The difference between this one and ExecutionContextMainFT is that this one allows to us to have a fixed thread pool with 1 thread.
N.B.: places where it is advisable to have a fixed thread pool:
-
the pool that handles incoming HTTP requests (thus providing some back-pressure by slowing down client requests)
-
the pool that handles the connections to your DB, thus back-pressuring your DB server.
As a side-note, you probably want your HTTP pool to be smaller than your DB pool (since you might be doing multiple DB calls per request).
- Value Params
- daemons
whether or not the threads in the pool should be daemons or not. see java.lang.Thread#setDaemon(boolean) for the meaning for daemon threads.
- maxThreads
The maximum number of threads in the pool. Always defaults to 1 thread, if you accidentally give it a value < 1.
- threadNamePrefix
prefixes this name to the ThreadID. This is the name that usually shows up in the logs. It also prefixes the maxThread count.
- Returns
A fixed thread pool
Like defaultMainExecutionContext, but with a custom upper bound for threads, instead one based on the number of available processors
Like defaultMainExecutionContext, but with a custom upper bound for threads, instead one based on the number of available processors
A simple thread pool with one single thread. Be careful how you use it.
!!! WARNING !!! Prefer Pools.singleThreaded, unless you know what you are doing. The behavior the the Execution context itself is the same for both, but the former is actually safer to use :)
A simple thread pool with one single thread. Be careful how you use it.