You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
ROS2 supports intra-process communication when composing multiple nodes in a single process. It additionally can avoid doing any copies of the data when published using std::unique_ptr<MessageT> and subscribed using shared_ptr<const MessageT> or std::unique_ptr<MessageT> (at most 1 subscriber)
This PR is my attempt to add support for publishing using std::unique_ptr without breaking any of the existing APIs.
The idea is that:
Each publisher plugin can decide whether they support publishing using unique ptr (for now I don't see how any other plugin than raw can take advantage of the ownership).
The new Publisher::publish(sensor_msgs::msg::Image::UniquePtr message) method first publishes using the const reference to plugins that don't support std::unique_ptr, then moves the ownership of the message to (at most 1) plugin that supports it.
If there is more than one plugin that supports std::unique_ptr and has subscriptions, we pass the ownership to only one such plugin (the first we find), and for the rest we still use const reference, delegating doing any extra copies to plugin implementations.
are you planning to make some changes in image_transport_plugins too ? using this new API ?
I don't see how the compressed image transports can take advantage of the image ownership as they still have to copy the data, BUT they might avoid copying the resulting compressed data by publishing it using std::unique_ptr so I was planning to make them use the more generic publish(const sensor_msgs::msg::Image & message, const PublisherT & publisher) method to publish unique_ptr instead of const reference.
I marked the method as deprecated. Also, I think that we should not add default implementations that are empty or don't make sense. I also can't make these methods abstract, so instead I just throw exceptions. @ahcorde What do you think?
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
bjsowa
force-pushed
the
raw_intra_process_pub
branch
from
ROS2 supports intra-process communication when composing multiple nodes in a single process. It additionally can avoid doing any copies of the data when published using
std::unique_ptr<MessageT>and subscribed usingshared_ptr<const MessageT>orstd::unique_ptr<MessageT>(at most 1 subscriber)This PR is my attempt to add support for publishing using
std::unique_ptrwithout breaking any of the existing APIs.The idea is that:
rawcan take advantage of the ownership).Publisher::publish(sensor_msgs::msg::Image::UniquePtr message)method first publishes using the const reference to plugins that don't supportstd::unique_ptr, then moves the ownership of the message to (at most 1) plugin that supports it.std::unique_ptrand has subscriptions, we pass the ownership to only one such plugin (the first we find), and for the rest we still use const reference, delegating doing any extra copies to plugin implementations.Related issues/prs:
#212
#215
#216 (kinda)