1

I find the dynamic shrinking functionality generally obsolete, all reasons I can think of (stack size of 1 MB, or additional file descriptor, tiny additional OS scheduling overhead) do not seem to counterweight the latency overhead of firing up a new thread lazily.

What would be the best use case for an automatically shrinking (timeout-based) thread pool (Posix threads on x86_64 hardware) to demonstrate it is still a usable pattern?

bobah
  • 18,364
  • 2
  • 37
  • 70

1 Answers1

1

Shrinking a thread pool will free up resources (mostly RAM) that will then become available for other processes running on the same computer or perhaps on a different VM running on the same hardware. The RAM can also be used to speed things up via caching.

See also:

In general the consensus seems to be that if it's a short lived task a thread pool will offer performance benefits. For longer lived threads it will be less significant.

neuhaus
  • 3,886
  • 1
  • 10
  • 27
  • Can you please elaborate re: what RAM (apart from 1MB of stack) and clarify what you mean by leaking stack memory (I don't think it is possible in principle). – bobah Oct 10 '17 at 11:34
  • Threads can be large, having fewer of them consumes less memory. You are right about the stack, it's hard to leak that :) – neuhaus Oct 10 '17 at 11:39
  • RAM footprint of a thread parked in a pool is just 1 MB of stack, nothing else. – bobah Oct 10 '17 at 11:40