-
Notifications
You must be signed in to change notification settings - Fork 418
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
Trigger the intraprocess guard condition with data #2164
Conversation
If the intraprocess buffer still has data after taking, re-trigger the guard condition to ensure that the executor will continue to service it, even if incoming publications stop. Signed-off-by: Michael Carroll <michael@openrobotics.org>
Signed-off-by: Michael Carroll <michael@openrobotics.org>
67a1607
to
0100d73
Compare
Signed-off-by: Michael Carroll <michael@openrobotics.org>
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.
Looks good to me with green CI.
Signed-off-by: Michael Carroll <michael@openrobotics.org>
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.
@mjcarroll i think this is one of the critical bug, should we backport this to humble? i am inclined to backport since many application possibly meets this issue when they use StaticSingleThreadedExecutor
? (no backporting is also fine, since this is under experimental.)
CC: @clalancette @alsora
I think it is a bug, but unclear how many people would actually run into it. If you have anything else that wakes up the executor, it will still service the intraprocess subscriptions unconditionally (which may be another bug, but seems to work). In the case of the current |
yeah, that is we never know... 💭 probably we can give it a couple of weeks to see if nothing happens on rolling, and then backport to humble. any objections? |
No objections! better safe than sorry. |
@Mergifyio backport to humble |
❌ No backport have been created
GitHub error:
|
If the intraprocess buffer still has data after taking, re-trigger the guard condition to ensure that the executor will continue to service it, even if incoming publications stop. Signed-off-by: Michael Carroll <michael@openrobotics.org> (cherry picked from commit 5f9695a)
😢 @Mergifyio backport humble |
@mjcarroll I guess i did something wrong and lead mergifyio not to create backport PR for humble ... 😓 So i just create backport PR for humble, could you take a look at #2167? |
If the intraprocess buffer still has data after taking, re-trigger the guard condition to ensure that the executor will continue to service it, even if incoming publications stop. Signed-off-by: Michael Carroll <michael@openrobotics.org>
If the intraprocess buffer still has data after taking, re-trigger the guard condition to ensure that the executor will continue to service it, even if incoming publications stop. Signed-off-by: Michael Carroll <michael@openrobotics.org>
If the intraprocess buffer still has data after taking, re-trigger the guard condition to ensure that the executor will continue to service it, even if incoming publications stop. Signed-off-by: Michael Carroll <michael@openrobotics.org>
If the intraprocess buffer still has data after taking, re-trigger the guard condition to ensure that the executor will continue to service it, even if incoming publications stop. Signed-off-by: Michael Carroll <michael@openrobotics.org>
If the intraprocess buffer still has data after taking, re-trigger the guard condition to ensure that the executor will continue to service it, even if incoming publications stop. Signed-off-by: Michael Carroll <michael@openrobotics.org>
If the intraprocess buffer still has data after taking, re-trigger the guard condition to ensure that the executor will continue to service it, even if incoming publications stop. Signed-off-by: Michael Carroll <michael@openrobotics.org> (cherry picked from commit 5f9695a) Co-authored-by: Michael Carroll <michael@openrobotics.org>
If the intraprocess buffer still has data after taking, re-trigger the guard condition to ensure that the executor will continue to service it, even if incoming publications stop. Signed-off-by: Michael Carroll <michael@openrobotics.org>
If the intraprocess buffer still has data after taking, re-trigger the guard condition to ensure that the executor will continue to service it, even if incoming publications stop.
I found this bug when working on #2142. There is a situation where if an intraprocess publisher sends all of it's messages before the subscription starts servicing it, then the executor will fail to service the entire queue.
Note that in the current
rclcpp
implementation, this really only impacts theStaticSingleThreadedExecutor
, as theSingleThreadedExecutor
andMultiThreadedExector
both automatically trigger the waitset at the end of an executable cycle. I discovered this because the rclcpp::Waitset based executor also does not recompute work. I added the test to run against all executors to prevent regression.