forked from ros2/rclcpp
-
Notifications
You must be signed in to change notification settings - Fork 2
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
Iron: Support intra-process communication: Clients & Services & Actions #129
Open
mauropasse
wants to merge
12
commits into
irobot-ros:irobot/iron
Choose a base branch
from
mauropasse:mauro/irobot-iron
base: irobot/iron
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The initial implementation of the events-executor contained a bug where the executor would end up in an inconsistent state and stop processing interrupt/shutdown notifications. Manually adding a node to the executor results in a) producing a notify waitable event and b) refreshing the executor collections. The inconsistent state would happen if the event was processed before the collections were finished to be refreshed: the executor would pick up the event but be unable to process it. This would leave the `notify_waitable_event_pushed_` flag to true, preventing additional notify waitable events to be pushed. The behavior is observable only under heavy load. Signed-off-by: Alberto Soragna <[email protected]>
…it-test (ros2#2187) Signed-off-by: Alberto Soragna <[email protected]>
This is to ensure callbacks are destroyed last on entities destruction, avoiding the gap in time in which rmw entities hold a reference to a destroyed function. Signed-off-by: Mauro Passerino <[email protected]> Co-authored-by: Mauro Passerino <[email protected]>
…ros2#2276) * Do not crash Executor when send_response fails due to client failure. Related to ros2/ros2#1253 It is not sane that a faulty client can crash our service Executor, as discussed in the referred issue, if the client is not setup properly, send_response may return RCL_RET_TIMEOUT, we should not throw an error in this case. Signed-off-by: Zang MingJie <[email protected]> * Update rclcpp/include/rclcpp/service.hpp Co-authored-by: Tomoya Fujita <[email protected]> Signed-off-by: Zang MingJie <[email protected]> * address review comments. Signed-off-by: Tomoya Fujita <[email protected]> --------- Signed-off-by: Zang MingJie <[email protected]> Signed-off-by: Tomoya Fujita <[email protected]> Co-authored-by: Zang MingJie <[email protected]>
…iron Do not crash Executor when send_response fails due to client failure.…
We need this because it is possible for one thread to be handling the on_parameter_event callback while another one is detaching the node. This lock will protect that from happening. Signed-off-by: Chris Lalancette <[email protected]>
…on-params-event Iron: Fix data race on parameter event
Both the EventHandler and its associated pubs/subs share the same underlying rmw event listener. When a pub/sub is destroyed, the listener is destroyed. There is a data race when the ~EventHandlerBase wants to access the listener after it has been destroyed. The EventHandler stores a shared_ptr of its associated pub/sub. But since we were clearing the listener event callbacks on the base class destructor ~EventHandlerBase, the pub/sub was already destroyed, which means the rmw event listener was also destroyed, thus causing a segfault when trying to obtain it to clear the callbacks. Clearing the callbacks on ~EventHandler instead of ~EventHandlerBase avoids the race, since the pub/sub are still valid. Signed-off-by: Mauro Passerino <[email protected]>
…a-race-events Fix data race in ~EventHandlerBase
Signed-off-by: Mauro Passerino <[email protected]>
Signed-off-by: Mauro Passerino <[email protected]>
mauropasse
changed the title
Support intra-process communication: Clients & Services & Actions
Iron: Support intra-process communication: Clients & Services & Actions
Nov 8, 2023
apojomovsky
force-pushed
the
irobot/iron
branch
2 times, most recently
from
August 12, 2024 18:42
cce9a1a
to
f27bdbf
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Support intra-process communication: Clients & Services & Actions