Open foreverpersist opened 6 years ago
I think the whole point of a thread pool (statically created threads at init time) is to avoid the overhead of creating/destroying threads repeatedly during run time. The penalty for having idle threads in the background is basically none, so it's not worth the effort to destroy them.
I think the whole point of a thread pool (statically created threads at init time) is to avoid the overhead of creating/destroying threads repeatedly during run time. The penalty for having idle threads in the background is basically none, so it's not worth the effort to destroy them.
Sure, creating/destroying threads may bring some overhead, but is it significant performance overhead?It may be difficult to estimate each workload when creating threads statically. Too many static threads may waste resources, and too few threads can not deal with tasks well. That is why I think it is meaningful to create/destroy threads dynamically.
Late to the party but my two cents
Other than the fact that dynamically allocating the threads would make this not a thread pool: embedded applications and other applications where heap space and cycles are severely limited exist, and using malloc
in many codebases is frowned upon. The main point of a threadpool is that you can have a sort of fake dynamic allocation depending on how many jobs come through, because malloc
and free
are very expensive operations compared to leaving a thread idle.
Current threadpool in this project creates threads statically when it is initialized. And number of threads is fixed during its lifecycle.
Why not create and destroy threads dynamically?
Create:
Destroy: