Fix for HW reset while RGB streaming #7647
Conversation
check out the new fix with mutex |
|
Hi @nohayassin |
ev-mp
changed the title
| { | ||
| // joinable() only checks that the thread's alive -- but we don't want to join | ||
| // if we're here from within the worker thread itself! | ||
| if (std::this_thread::get_id() != _worker.get_id()) |
There was a problem hiding this comment.
Is this a preventive action ? The dtor ought not to be called from the spinoff thread anyway.
If it is - it can mark a circular dependency that we need to review.
Also the worker's thread's lifespan shall be encapsulated within the invoking object as it uses its resources, thus detach can be dangerous.
There was a problem hiding this comment.
The dtor can get called from within the worker thread because of shared_ptr's reference counting:
device holds subdevice_model holds processing_block_model-list holds filter-ptr holds worker thread running in the bg
device goes away
~device calls ~subdevice_model calls ~processing_block_model calls ~filter-ptr
Here is where it gets interesting:
We don't want to destroy the filter until we're in a good place in the worker thread, because the worker thread is dependent on data that sits in there. So we have the worker thread lock the filter-ptr. But this means that, once the shared_ptr is released, the ~filter gets called and we're in the worker thread.
I'll hold off on the merge until you give your OK @ev-mp
There was a problem hiding this comment.
And, by the way --
I asked Noha to write a unit-test for this. Should be doable. She opened a ticket to track it.
|
Continued in #7698 |
track on DSO-15827
Fixed race between face detection thread and main thread of post processing filter that happens after HW reset