-
Notifications
You must be signed in to change notification settings - Fork 4.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Dispatcher deadlock workaround #10517
base: development
Are you sure you want to change the base?
Conversation
@@ -195,6 +195,7 @@ device::device(std::shared_ptr<context> ctx, | |||
|
|||
device::~device() | |||
{ | |||
_context->stop_device_watcher(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seems like it'd work, sure -- but why stop the context picking up new devices?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@v-lopez Can you suggest a better solution to this issue?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Haven't looked into the issue further. But I've been using this since then and I haven't appreciated any side effects.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@v-lopez
First, thanks for the PR, we appreciate it.
However, after reading the origin thread I am a little confused, as it seems to mix ROS (initial_reset) and plain libRS where the fix was made.
Can you provide a way for this deadlock to be reproduced with librealsense, either in C++ or Python? Once I understand how to reproduce I can add it to our unit-tests and see if I can solve it. Otherwise we'll likely direct it to our ROS guy to try and reproduce and see if the problem is there.
Hi, |
Hi @Milnaye , could you please give more details about your test scenario?
By this I assume, you have one camera always connected and the another camera is connected after calling the launch command. Please correct me if I'm wrong. For which camera are you trying to do 'initial_reset'? The one which is already connected or the one you are connecting after calling launch command or for both? |
Hi @Arun-Prasad-V, After reading again what i wrote, i can understand that I wasn't clear at all... On our robot, the two cameras stay connected all the time, the issue happens only on the second camera checked by the ros node. I'm able to consistently reproduce the issue on a computer with only one camera, by lauching the ros node before plugging the camera. It happen only with initial_reset to true. I hope it makes more sense now :) |
Hi @Milnaye, Thanks for the details. If I understand correctly, you have explained two scenarios where the issue is seen:
Could you please share
Also, please share the below details:
|
Hi @Arun-Prasad-V, Your description of both scenario are corrects. For the scenario 2, the second camera is not connected.
On scenario 1, we use a python launch file which load the cameras settings and some node parameters. Both camera node are defined separately in this launch file but except the serial number and the usb port, the way we launch them is similar. camera_advanced_settings.json.txt This is a error log quite old, but it's still the same. node-26 correspond to "camera_left" and node-27 to "camera_right".
On scenario 2, I use the command The result log file is similar |
@Milnaye , @v-lopez , This issue has been fixed in the 'development' branch. Please refer #10482 (comment). Please try and let us know if you need any further help. |
Details on #10482
Stopping _device_watcher before unregistering callbacks.