fix abort in some cases with DDS

[AviaAv]

Fixed an issue where we randomly see an error where abort() is called after we finish using DDS (in the d'tor), added a try catch block due to the race condition there
Tracked on: [LRS-1212]

[Nir-Az]

@maloel can you review?
We saw sporadic crash by this 2 lines:

librealsense/third-party/realdds/src/dds-network-adapter-watcher.cpp

Line 63 in b5e1c7c

_th.detach(); // so it's not joinable

librealsense/third-party/realdds/src/dds-network-adapter-watcher.cpp

Line 77 in b5e1c7c

_th.join();

the condition for joinable and the actual join actions are not atomic.
Maybe we can drop the join at all?

Currently this issue was also raised by validation as a critical BUG.

[maloel]

Please see the comments; otherwise good to go

[AviaAv]

Seeing we still could throw because of a failed join, even with the try catch, updating to a different approach of removing the thread detach. As far as I've noticed, we don't wait additional time because of this change

[Nir-Az]

Seeing we still could throw because of a failed join, even with the try catch, updating to a different approach of removing the thread detach. As far as I've noticed, we don't wait additional time because of this change

It's probably fast enough but the theoretical time to wait is 15 sec.
@maloel what do you think?

[maloel]

In general, after reviewing the code, I think removing the detach() should be good - I arrived at the same conclusion. I assume this was tested and works.
I don't think a 15-second period of waiting on exit will happen: we reset the shared-ptr and the current code will pick up on it.
There is a small chance that we're done but waiting on the thread, which will still trigger our callbacks while we're waiting to destruct. To fix this we need additional changes.
About the join() throwing, I think it still makes sense to put a try-catch block just to protect against some unforeseen issues.

[Nir-Az]

In general, after reviewing the code, I think removing the detach() should be good - I arrived at the same conclusion. I assume this was tested and works. I don't think a 15-second period of waiting on exit will happen: we reset the shared-ptr and the current code will pick up on it. There is a small chance that we're done but waiting on the thread, which will still trigger our callbacks while we're waiting to destruct. To fix this we need additional changes. About the join() throwing, I think it still makes sense to put a try-catch block just to protect against some unforeseen issues.

I agree
@AviaAv lets add it

[Nir-Az]

LGTM