Design a Thread Pool / Task Executor

Design the class model and public APIs for a reusable thread pool: an in-process component that owns a fixed set of worker threads, accepts submitted units of work, runs them on those workers, and hands each caller a handle to observe the result. The pool exists so callers stop spawning a raw thread per task; they hand you a task and get back a future.

Operating context. One process, many application threads submitting tasks concurrently into a single shared pool. Tasks are short-to-medium CPU or IO work, arriving in bursts far faster than they complete, so the queue backs up. Workers pull from a shared, bounded task queue; the number of workers is fixed at construction. A caller may submit fire-and-forget work, or work whose return value it will later read (blocking until done, optionally with a timeout) and whose failure it must be able to observe as a raised exception rather than a silently swallowed error. The pool must also shut down cleanly: either drain everything already accepted, or stop promptly and report what never ran.

Out of scope. The threading primitives themselves (assume you already have threads, mutexes, condition variables, and atomics — do not implement a mutex); distributed or cross-machine work dispatch; task persistence and retry-after-crash; per-task priority scheduling and cron-style timers; and the concrete business logic inside any task. Design the executor and its contracts, not the OS scheduler.

What to produce. The class hierarchy (the executor interface, the pool implementation, the worker, the task queue, the submitted-task wrapper, and the returned future/handle), the public API each exposes, and the lifecycle state machine (running -> shutting-down -> terminated). Be explicit about: how a submitted callable becomes a future the caller can await and read a value or an exception from; how the bounded queue plus a pluggable rejection policy give you backpressure when the pool is saturated; how graceful shutdown differs from an immediate stop and what each returns; and how workers, submitters, and the shutdown path coordinate on shared state without races, deadlock, or lost wakeups.