TBH that’s a deliberate leak, because there’s a risk that somebody could write a static destructor that performs a sleep, which could crash if that handle has already been destroyed.
That seems like overkill for the sake of one handle. The thing is that it’s not really a “leak”, because the handle is required for the lifetime of the app, and the OS cleans it up afterwards, so everything works perfectly well the way it’s written.
I guess I could add some debug-only code that releases the handle, just to avoid the warning…
I have been reported of the leak even with the Release build though… isn’t there any other way? For example, doing the other way around, and jasserting the object to be initialised when used?
wait wait, I think there is a better way to handle this: what about binding the existence of that handle wrapper to the existence of the Thread class itself, for example making it a static member of the class itself? This way, we should be sure that the object doesn’t get destroyed until there are no more calls to Thread::sleep to be expected (am I right?)