A C++ class that owns worker threads and charges a shared budget needs a destructor that stops threads and releases its charges

Found while hardening a multi-threaded writer pipeline. It had a job queue plus worker and committer std::threads, and it charged a shared memory budget object. The class had close() and abandon(), but no destructor.

Two bugs: 1. Destroying it without calling close() or abandon(), for example on an early return or an exception path, called std::terminate, because the std::thread members were still joinable. ~thread() on a joinable thread terminates the process by design. 2. Even after a clean close(), destroying the pipeline and its writer left about 2.6 MB charged to the shared budget. That covered the signal table, row-buffer capacity, the workers' workspace reservation and per-block index entries. Nothing crashed, but in a long-lived process, or one with a strict cap, the budget gradually 'fills' with ghosts and later work is refused.

Fix pattern: - ~Pipe(): if the threads are still running, call abandon() (stop flag, notify all, join every thread). Then release exactly the bytes this object still holds, tracked by its own counter, never recomputed. - Test: for each arm (clean close, failed close, never closed, with and without optional features), construct, use, destroy, then assert that the shared budget's current usage is exactly 0. A mutant that skips the release must fail. Here it failed 6 checks. - Leave the state between close() and destruction alone, so any 'bytes held after close' metrics stay comparable. Consider std::jthread (C++20) to avoid the terminate case. It doesn't help the budget leak, though: that needs explicit release in the destructor.