Clarify ConstSharedPtr achieves zero-copy - #7064
Conversation
MShields1986
changed the title
Re-add the plain const T & callback type to the list of subscriber signatures that do not achieve zero-copy, addressing reviewer feedback that this case was dropped from the previous clarification. Co-Authored-By: MShields1986 <matthew.shields@dexory.com>
| This is because we're publishing and subscribing with ``std::unique_ptr``\ s which allow ownership of a message to be moved around the system safely. | ||
| You can also publish and subscribe with ``const &`` and ``std::shared_ptr``, but zero-copy will not occur in that case. | ||
| You can also subscribe using a ``const std::shared_ptr<const T> &`` (``ConstSharedPtr``) callback, which shares immutable ownership of the message and achieves zero-copy even with multiple subscribers, so long as a ``std::unique_ptr`` was passed to the publisher. | ||
| Subscribing with a plain ``const T &`` or a mutable ``std::shared_ptr<T>`` will not achieve zero-copy. |
There was a problem hiding this comment.
Curious if you still see this with a newer version of rclcpp (Lyrical/Rolling). IIRC, const T & should now have the same effect as const std::shared_ptr<const T> or std::shared_ptr<const T>.
There was a problem hiding this comment.
You can see exactly what I tested in more detail here. I could add cases but would be good to get a full matrix of what anyone wants to see first.
Might be scope creep for this specific PR though.
There was a problem hiding this comment.
Coincidentally, I actually wrote a similar Discourse post at the beginning of this year documenting these behaviors (though mine is not as comprehensive as yours). That post eventually led to a PR fixing the const T & case, so I think this sentence may no longer be accurate.
My two cents would be to validate it and update the sentence if needed, or simply remove it since the tutorial doesn't mention it anyway.
5 participants
Description
The existing note on subscriber callback types incorrectly implied that no
shared_ptrvariant could achieve zero-copy, grouping mutableshared_ptr<T>andConstSharedPtrtogether.This is misleading:
const std::shared_ptr<const T> &(ConstSharedPtr) uses immutable shared ownership and delivers zero-copy to multiple intra-process subscribers simultaneously, making it the correct pattern for one-to-many composition.Changes:
shared_ptrsentence in the two-node pipeline section to distinguishConstSharedPtr(zero-copy capable) from mutableshared_ptr<T>(not zero-copy)ConstSharedPtrcallbacks avoid the fan-out copy penalty thatUniquePtrincurs in one-to-many graphsA more detailed write up with tests and findings is available here
Did you use Generative AI?
No
Additional Information
The correction to the
shared_ptrnote is a factual fix as the previous wording could lead readers to incorrectly avoidConstSharedPtrin one-to-many scenarios where it is the appropriate tool.