Title is misleading. The author seems to mask what they're saying in a way that makes it really easy to conclude that their point is "Thread pools are bad, so I'll show you a better way." In fact, the proposed better way is ThreadPools(tm).
In fact, "The Unscalable, Deadlock-Prone, Thread Pool" is only referring to a badly used ThreadPool. Like, really badly: the strawman that forms the crux of the argument is that you are only using the same ThreadPool for all of your disparate forms of work.
> My favourite approach assigns one global thread pool (queue) to each function or processing step.
Yes, creating different thread pools for different kinds of work is a much better way to use them...
The .NET libraries make it easy to use the default thread pool (a single pool). If other libraries are similar, then I wouldn't consider this a complete straw man.
Yes, but the .NET thread pool is auto-tuning, although very badly, with at least a second latency to increased workload. For bursty requests that could be done within a few hundred milliseconds it is a bad fit. But you can't DOS your batch processing server so easily.
Agreed. I feel that he should engage with the actor model in this article or a subsequent one because it seems to me like the type of abstraction he’s searching for. E.g. where each actor generally performs one type of work, each has a mailbox with a variety of parallelism strategies, message passing semantics discourage deadlock scenarios... Not a perfect solution but one to discuss when talking about the problems he’s trying to solve.
In fact, "The Unscalable, Deadlock-Prone, Thread Pool" is only referring to a badly used ThreadPool. Like, really badly: the strawman that forms the crux of the argument is that you are only using the same ThreadPool for all of your disparate forms of work.
> My favourite approach assigns one global thread pool (queue) to each function or processing step.
Yes, creating different thread pools for different kinds of work is a much better way to use them...