-
Notifications
You must be signed in to change notification settings - Fork 1.3k
Clarify ConstSharedPtr achieves zero-copy #7064
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
base: lyrical
Are you sure you want to change the base?
Changes from 2 commits
d9ad00d
8df0ab8
b997504
5b0421a
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -163,7 +163,8 @@ In this case, since they only come once per second, usually only the first messa | |
| Finally, you can see that "Published message..." and "Received message ..." lines with the same value also have the same address. | ||
| This shows that the address of the message being received is the same as the one that was published and that it is not a copy. | ||
| 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. | ||
|
MShields1986 marked this conversation as resolved.
Outdated
|
||
| Subscribing with a plain ``const T &`` or a mutable ``std::shared_ptr<T>`` will not achieve zero-copy. | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Curious if you still see this with a newer version of rclcpp (Lyrical/Rolling). IIRC,
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 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.
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 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. |
||
|
|
||
| The cyclic pipeline demo | ||
| ^^^^^^^^^^^^^^^^^^^^^^^^ | ||
|
|
@@ -377,6 +378,12 @@ It can be, however, delivered to one of them. | |
| Which one would get the original pointer is not defined, but instead is simply the last to be delivered. | ||
| And so one of the images being viewed is the original, with all the pointers the same, and the other is a copy of the original image, made between the ``watermark_node`` and one of the ``image_view_node`` instances, which will have a different pointer for the third line of text. | ||
|
|
||
| To avoid this copy in a one-to-many pipeline, subscribers can use ``ConstSharedPtr`` | ||
| (i.e. ``const std::shared_ptr<const T> &``) callbacks instead of ``UniquePtr``. | ||
| The publisher retains a single immutable shared object and delivers it to all intra-process | ||
| subscribers without copying, at the cost of no longer being able to mutate the message after | ||
| publishing. | ||
|
MShields1986 marked this conversation as resolved.
Outdated
|
||
|
|
||
| Pipeline with inter-process viewer | ||
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | ||
|
|
||
|
|
||
Uh oh!
There was an error while loading. Please reload this page.