-
Notifications
You must be signed in to change notification settings - Fork 79
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
getMTNodeHandle doesn't result in more callbacks in parallel on a single topic #77
Comments
lucasw
changed the title
getMTNodeHandle doesn't result in more callbacks in parallel
getMTNodeHandle doesn't result in more callbacks in parallel on a single topic
Jul 28, 2018
lucasw
added a commit
to lucasw/nodelet_demo
that referenced
this issue
Jul 28, 2018
… callback topic is still single threaded, the multi threading is only across different subscribers ros/nodelet_core#77
By default, concurrent callbacks by the same Subscriber are not allowed. However, you can enable them by setting the This issue explains the increase in cpu. |
lucasw
added a commit
to lucasw/nodelet_demo
that referenced
this issue
Sep 23, 2021
Thanks, I got that working like this and I can see the concurrency happening correctly:
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
From https://answers.ros.org/question/298750/getmtnodehandlegetmtprivatenodehandle-doesnt-result-in-additional-callbacks-but-does-take-more-cpu/
I assumed from the line "getMTNodeHandle() and getMTPrivateNodeHandle() callbacks will be distributed over the thread pool of the manager" from http://wiki.ros.org/nodelet#Threading_Model that switching a subscriber in a nodelet from using getNodeHandle() would result in callbacks on a single topic distributed over threads available in the nodelet manager pool and would result in a higher callback rate when a single thread can't keep up.
What I've found in https://github.com/lucasw/nodelet_demo is that there are no additional callbacks, but I can see a huge increase in cpu.
Does a single topic callback still only get one thread, but multiple callbacks for multiple topics could take as many threads as there are topics? I'll test this out.
Are there additional steps to make a nodelet multi-threaded?
A possible limited workaround would be to have a generic demultiplexer nodelet (which ought to be nearly zero cost with no copies or deserializations) and multiple instances of the nodelet subscribing to 1/n of the upstream topic rate. Or if the above comment about a given topic being single thread is true, a single nodelet could have multiple subscribers to the multiple topics that the demux distributed.
Related to #25
The text was updated successfully, but these errors were encountered: