As discussed elsewhere (ros2/rmw_fastrtps#343 (review)), the current best practice is to use the closest equivalent to the asynchronous publishing mode that some DDS implementations have for implementing rmw_publish(). Right now, this repository does not change the QoS for this when creating a publisher and therefore I assume it uses something like the synchronous publishing mode.
So a few questions:
- does cyclone have an "asynchronous publishing mode"-like setting?
- if not, what is the blocking behavior of publishing in cyclone, or more generally what happens when you call publish?
If there is an equivalent mode then it would be best to switch to it by default, even if it has a negative performance impact for some cases.
We can/should separately decide if the best practice should be adjusted, but until that time we should try to keep our rmw implementations as consistent as possible.
And for some more background...
We prefer the asynchronous publishing mode (for now) because:
- it more closely models how it works in ROS 1 which we're trying to emulate
- it allows for large data (fragmentation) on the several other DDS based middlewares (Connext and FastRTPS)
We're aware that there are performance (latency and throughput) considerations here, and we've already discussed having an option in the ROS API to allow this to be configurable, see: ros2/ros2#255, or at least dynamic (smarter), see: ros2/rmw_connext#190.
But until we decide to change something (and therefore change all the implementations together), I consider this a bug in the implementation of rmw_cyclonedds_cpp, i.e. that it does not implement publish with an "asynchronous publishing mode"-like mode (note this is not part of the DDS standard as far as I can see, but it is a common configuration).
As discussed elsewhere (ros2/rmw_fastrtps#343 (review)), the current best practice is to use the closest equivalent to the asynchronous publishing mode that some DDS implementations have for implementing
rmw_publish(). Right now, this repository does not change the QoS for this when creating a publisher and therefore I assume it uses something like the synchronous publishing mode.So a few questions:
If there is an equivalent mode then it would be best to switch to it by default, even if it has a negative performance impact for some cases.
We can/should separately decide if the best practice should be adjusted, but until that time we should try to keep our rmw implementations as consistent as possible.
And for some more background...
We prefer the asynchronous publishing mode (for now) because:
We're aware that there are performance (latency and throughput) considerations here, and we've already discussed having an option in the ROS API to allow this to be configurable, see: ros2/ros2#255, or at least dynamic (smarter), see: ros2/rmw_connext#190.
But until we decide to change something (and therefore change all the implementations together), I consider this a bug in the implementation of
rmw_cyclonedds_cpp, i.e. that it does not implement publish with an "asynchronous publishing mode"-like mode (note this is not part of the DDS standard as far as I can see, but it is a common configuration).