A couple days ago, a co-worker and I stumbled upon an unintended constraint in some of the thread pool abstractions in the system we're working on. These threading abstractions leaned too heavily on the underlying ThreadPoolExecutor in Java for their semantics and did a poor job of hiding these from client code. Specifically, this class has corePoolSize and maximumPoolSize settings. The former is often misconstrued as a minimum pool size, which it's not; it's actually the maximum number of threads that should be created automatically before the work queue reaches its maximum size. However, when this abstraction is well-known at a low level and then translated to a higher-level abstraction, that distinction may be lost in translation. When treated as a minimum size, it fails to meet expectations in a rather significant way. For instance, if you have the core size configured to be 1, the max size configured to be 20, and are using an unbounded work queue...