The particular case occurs often during testing, when a device is created and then quickly destroyed.
The problem is that CThreadBase::start does not wait for the thread to actually start before returning. That means that if the caller calls stop (usually indirectly via diableHandler or something similar), the stop function will set the thread to alive = false, and join (wait indenitely).
Because the thread didn't actually start yet, the alive = false gets overwritten when the thread actually starts, so the caller waits for a thread to end which just actuallly started and gets stuck.
I think a semaphore will do the trick to coordinate this and make sure start waits for the thread before returning.
The particular case occurs often during testing, when a device is created and then quickly destroyed.
The problem is that
CThreadBase::startdoes not wait for the thread to actually start before returning. That means that if the caller callsstop(usually indirectly viadiableHandleror something similar), thestopfunction will set the thread to alive = false, and join (wait indenitely). Because the thread didn't actually start yet, thealive = falsegets overwritten when the thread actually starts, so the caller waits for a thread to end which just actuallly started and gets stuck.I think a semaphore will do the trick to coordinate this and make sure
startwaits for the thread before returning.