Repository navigation
Mutually exclusive callback group hangs #832
Description
The root cause for this issue is due to a combination between the multithreaded executor and the mutually exclusive callback group used for all the ROS topics.
When the executor collects all the references to the subscriptions, timers and services, it skips the mutually exclusive callback_groups which are currently locked (ie: being processed by another thread).
This cause the resulting waitset to only contain the guard pointers.
If there is no activity on those guards, the thread will wait for work forever in the get_next_executable and block all other threads.
Activity
ivanpauno commentedon Sep 5, 2019
I have think about this (again), and I haven't found a way of avoiding the race condition without blocking others threads of executing an available executable (which is the whole point of multithreaded executors), or without refactoring the executor completely.
Therefor, I'm deleting me as assignee ...
ivanpauno commentedon Sep 12, 2019
@guillaumeautran Could you provide an example of this hang?
guillaumeautran commentedon Jan 14, 2021
Sorry for the extremely late reply. We obviously moved on and in the end, we ended up extending the multi-threaded executor and implementing our own (for several reasons).
Will close this issue is no-one else is experiencing problems.
ivanpauno commentedon Jan 14, 2021
Thanks for the reply!
I know the current multi-threaded executor has many quirks and isn't ideal, so it would be great if you can share what were the reasons to not use the current implementation and, if possible, explain how those were solved in your own implementation.
Move notification about ready for playback inside play_messages_from_…