Should theadpool create and destroy threads dynamically? about c-thread-pool HOT 3 OPEN

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.

from c-thread-pool.

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.

from c-thread-pool.

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.

from c-thread-pool.