ThreadPool takes ownership of its jobs, but as far as I can tell, TimeSliceThread does not. I could create something that receives callbacks when the TimeSliceClient jobs are finished and then delete them manually, but this seems error prone.
I’m wondering if the fact that TimeSliceThread doesn’t handle its own allocation is intentional, and I have misunderstood how it is supposed to work. I had assumed that you could add and remove clients dynamically, and fairly fast. Is it intended for this? If so, what is the recommended way for managing the lifetime of the clients?
I think the reason is because a TimeSliceClient never finishes. It is for ongoing tasks, e.g. the BufferingAudioSource uses it to make sure there is always enough audio in the buffer. That means it will return to be called again.
The lifetime is intentionally handled by the user of the TimeSliceClient. Only that user can know when the TSC is no longer needed.
It would be nice if the TimeSliceClient had a pointer/WeakReference to the containing TimeSliceThread so you can conveniently remove it from the TSC’s destructor, but you will need to add that yourself to your TimeSliceClient derived class.
