Skip to content
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
wants to merge 12 commits into
base: irobot/iron
Choose a base branch
from

Conversation

mauropasse
Copy link
Collaborator

Support intra-process communication: Clients & Services & Actions

alsora and others added 12 commits May 14, 2023 08:01
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]>
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]>
@mauropasse mauropasse changed the title Support intra-process communication: Clients & Services & Actions Iron: Support intra-process communication: Clients & Services & Actions Nov 8, 2023
@apojomovsky apojomovsky force-pushed the irobot/iron branch 2 times, most recently from cce9a1a to f27bdbf Compare August 12, 2024 18:42
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants