rclcpp does not support zero-copy intra-process communication for shared_ptr or std::move raw messages

[Yuchen966]

Generated by Generative AI

No response

Operating System:

Ubuntu 22

ROS version or commit hash:

humble

RMW implementation (if applicable):

No response

RMW Configuration (if applicable):

No response

Client library (if applicable):

No response

'ros2 doctor --report' output

No response

Steps to reproduce issue

1. Enable intra-process communication in a node:

rclcpp::NodeOptions().use_intra_process_comms(true)

2. Create a publisher:

auto pub = node->create_publisher<std_msgs::msg::Int32>("topic", 10);

3. Create a subscriber that accepts shared_ptr or shared ownership.

Publish a message using a shared_ptr, possibly moved:

    auto msg = std::make_shared<std_msgs::msg::Int32>();
    pub->publish(std::move(msg));

4. Observe whether the subscriber receives the same memory address as the published message.

Additionally, inspect the test function in rclcpp/test/rclcpp/test_intra_process_manager.cpp (lines 531–582).
The comment says it publishes a shared_ptr message, but the actual code only publishes std::unique_ptr.

Expected behavior

Publishing a shared_ptr (or std::move(shared_ptr)) should avoid deep copying if intra-process communication is enabled, and all subscribers use shared ownership.

Actual behavior

• In rclcpp, publishing a shared_ptr message always results in a deep copy, even if std::move() is used.
• The test case test_intra_process_manager.cpp incorrectly claims that the share_ptr message memory address is the same in intra processing communication, but the code publishes std::unique_ptr, so the intended case is not tested at all.

Additional information

Tutorial Intra-Process Communication documents that only std::unique_ptr can enable zero-copy communication, which is correct.

But this contradicts the design document, which implies that shared_ptr with same ownership can also be passed without copying.

It is theoretically possible to support zero-copy for shared_ptr in safe cases (e.g., use_count() == 1), or provide an opt-in behavior to avoid unnecessary copies.

[mjcarroll]

I agree that it appears that the documentation, test, and implementation have fallen out of sync.

In this case, the only way to guarantee that the publisher doesn't make modifications to the message after publishing is to completely relinquish ownership, which is what the std::unique_ptr allows for.

I think the other particularly dangerous situation in the use_count() == 1 case would be that there are one or more weak_ptrs that continue to point to the same shared_ptr. In that case you could do something like:

auto msg = std::make_shared<std_msgs::msg::Int32>();
msg->data = 100;
std::weak_ptr<std_msgs::msg::Int32> weak_msg = msg;

pub->publish(msg);

auto lockedPtr = weakPtr.lock();
lockedPtr->value.data = 200;

// What does the subscriber see?

I believe a std::move of a raw message structure should probably incur no copies, though, and that may be an oversight of the API.

CC: @alsora

[alsora]

Publishing a shared_ptr (or std::move(shared_ptr)) should avoid deep copying if intra-process communication is enabled, and all subscribers use shared ownership.

Yeah this is expected.
As far as I remember this was always the case, but you're right that some docs are not reflecting it.

I agree with @mjcarroll that shared pointers are not safe to be supported in the current implementation.

I believe a std::move of a raw message structure should probably incur no copies, though, and that may be an oversight of the API.

If the publisher has access to a raw pointer which is "safe" to publish intra-process (i.e. they can fully relinquish their ownership) I think that they should be able to just use a unique pointer instead.
The raw pointer requires the API to make extra assumptions that the user knows what they are doing, and I think that the cases where they can't use a unique ptr instead are very little to be worth it.

[Yadunund]

@Yuchen966 we discussed this topic in today's Waffle meeting and agreed that the right action here is to update documentation on the usage and expectations of these APIs. If you or someone else is willing to submit a PR, we'd be happy to review it.

[ros-discourse]

This issue has been mentioned on Open Robotics Discourse. There might be relevant details there:

https://discourse.ros.org/t/ros-news-for-the-week-of-june-23rd-2025/44508/1

[Yuchen966]

I agree with @alsora and @mjcarroll that implementing zero-copy for std::move-ed raw messages makes sense.

However, I also believe a zero-copy implementation could be beneficial for shared pointers. The reason is that even when using weak pointers, you need to lock them to access or modify the shared data. When that happens, the use_count increases above 1, which means a deep copy becomes necessary to avoid side effects.

However, I agree that everybody could just follow the guideline of "always using unique pointer to avoid zero copy, if you are not able to use unique pointer, then zero copy is not safe anyway", which makes the implementation of raw messages and shared pointers not that beneficial.

I am currently busy with something else so I don't really have time to implement this. For now I think update the doc would be the best choice.