moveit2
The MoveIt Motion Planning Framework for ROS 2.
Loading...
Searching...
No Matches
moveit::detail Namespace Reference

Functions

std::shared_ptr< std::mutex > registerNodeResetOnPreShutdown (rclcpp::Node::SharedPtr &node)

Function Documentation

◆ registerNodeResetOnPreShutdown()

std::shared_ptr< std::mutex > moveit::detail::registerNodeResetOnPreShutdown ( rclcpp::Node::SharedPtr & node)
inline

Arranges for node – a caller-owned rclcpp::Node::SharedPtr with static storage duration – to be reset from an rclcpp pre-shutdown callback (which runs before rcl_shutdown() tears down the associated RMW context), instead of being left to run its destructor during static destruction at process exit. Some RMW implementations (e.g. rmw_zenoh_cpp) abort the process if RMW calls are made after their own process-wide static state has already been torn down, which otherwise races against the unspecified destruction order of unrelated function-local static objects. See moveit/moveit2#3827.

Returns a mutex the caller must lock before reading or writing node afterwards, so a concurrent caller and pre-shutdown callback can't race on it.

Two independent, deliberate design choices:

A. Node capture: the callback references the caller-owned node slot itself, rather than strongly capturing the Node. A strong Node capture could create Context -> pre-shutdown callback -> Node -> Context: Context strongly owns every pre-shutdown callback registered on it, and Node (via its NodeBase) strongly owns its rclcpp::Context::SharedPtr, so a callback holding a shared_ptr to the Node would close that cycle. A plain reference cannot itself be part of a shared_ptr reference cycle, so this can't happen.

B. Guard/mutex capture: the callback captures the returned mutex by weak_ptr, not shared_ptr, so that in the "rclcpp::shutdown() is never called" static-destruction path, the caller-owned mutex – constructed immediately after node, so by the standard's reverse-order-of-completed-construction rule it is destroyed before node – is already gone by the time node itself is destroyed. The weak_ptr lock then fails if the callback fires while node is being (or has been) destroyed, so the callback never touches the node slot while its own static shared_ptr is itself being torn down, leaving node to be destroyed exactly as it would have been before this fix.

Definition at line 85 of file logger_detail.hpp.

Here is the caller graph for this function: