Comment 11 for bug 885802

Having thought more about resource cleanup as you suggest, I now realize that the epicsThread class is not compatible with your "another constructor" idea without major internal changes, which I am not willing to spend time on.

While callers would be responsible for managing their epicsThread objects, the new constructor has to allocate an internal 'struct runner' object derived from epicsThreadRunable that holds the function pointer and void *parm, and provides the run() method that epicsThreadCallEntryPoint() calls. The epicsThread holds a reference to this object.

In my original I can delete the equivalent 'struct caller' object immediately after calling the function, but in epicsThread the reference to the runner exists for the life of the epicsThread object, so user code could still call epicsThread::show(2) after the thread has exited, which calls the runner's virtual show() routine so *bang*. There is nowhere to do the cleanup of this object within the current epicsThread implementation.

My original idea adds about 40 lines of straightforward new code to epicsThread.cpp. Yours would require significant internal surgery to get working safely.