Completely depends on if these are actual "worker threads" or just dumb threads which have been over scheduled. If these are "worker threads", new workers are

Completely depends on if these are actual "worker threads" or just dumb threads which have been over scheduled. If these are "worker threads", new workers are scheduled when all other workers are blocked and work is available. This guarantees that idle CPU will always be scheduled with work. When workers unblock, they continue execution on their work and start picking up new work. The worker scheduler will stop scheduling new workers and the extra workers will go back to the pool of inactive workers. This is the idea behind a worker or thread pool, they get scheduled when its possible to do more work. A poor implementation of this idea will just hand work off to threads and then expect them to all execute in parallel, which will lead to negative performance impact. The problem with (some implementations of) async workers is that just scheduling more will result in the latter problem, work split across too many workers. This is especially true for workers implemented as entire processes. The problem this post brings up is that 1 to 1 mapping of workers to cores suffers from idle CPU due to unanticipated blocking. The general solution is to smartly distribute work over a pool of workers, and not blindly schedule a fixed number workers.