You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 text was updated successfully, but these errors were encountered:
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 callsstop
(usually indirectly viadiableHandler
or something similar), thestop
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 text was updated successfully, but these errors were encountered: