Do not force asynchronous publishing

[MiguelCompany]

Since eProsima/Fast-DDS#898, asynchronous publishing is not necessary by default. This PR lets the default value for the publishing mode (which is synchronous), which usually has better latency results.

[ivanpauno]

Left a question, otherwise LGTM!

[ivanpauno]

Can you apply the same three changes to rmw_fastrpts_dynamic_cpp (rmw_publisher, rmw_client, rmw_service)?

[MiguelCompany]

Can you apply the same three changes to rmw_fastrpts_dynamic_cpp (rmw_publisher, rmw_client, rmw_service)?

ups! done!

[ivanpauno]

CI including test_rclcpp, test_communication:

• Linux (unrelated failure)
• AArch64 (unrelated failure)
• OSX (unrelated failure)
• Windows

[JaimeMartin]

@ivanpauno is ok with you if we merge this? We need this change for the ongoing performance tests.

[ivanpauno]

@ivanpauno is ok with you if we merge this? We need this change for the ongoing performance tests.

I haven't merged yet, because I'm not sure of all the implications this PR has.
About performance tests, I think the order is the opposite. First, have a performance test framework that can measure performance of what we currently have. Then do performance improvements, and use the performance tests as a proof. Without performance tests, I have to blindy trust that performance does improve with this PR.

---

I still think the changes are reasonable. Adding @wjwwood for a second approval before merging.

[JaimeMartin]

The performance improves, yes. We have your performance tests replicated on our performance test machines. You can safely merge this.

[wjwwood]

Please do not merge this until I have time to review it.

I think this may be changing behavior in a significant way and is also causing the behavior of publish to be different from other rmw implementations.

Also I think that allowing the publishing mode to be changed via external xml is a very bad idea as I detailed in this discussion:

ros2/ros2#255

[wjwwood]

The code changes look fine, but I have to disagree with the change in general.

We picked asynchronous publishing in the past, see:

• rmw_fastrtps/rmw_fastrtps_cpp/src/rmw_publisher.cpp

  Line 153 in 3e0aea7

  publisherParam.qos.m_publishMode.kind = eprosima::fastrtps::ASYNCHRONOUS_PUBLISH_MODE;

• https://github.com/ros2/rmw_connext/blob/9de4488035ed6264a91f8d2948a88b7afca5522c/rmw_connext_shared_cpp/src/qos.cpp#L221
• OpenSplice doesn't use it, which I consider to be a bug (rmw opensplice implementation does not use asynchronous publishing rmw_opensplice#301) turns out OpenSplice is always asynchronous
• CycloneDDS uses synchronous, which I consider to be a bug (rmw cyclonedds implementation does not use asynchronous publishing rmw_cyclonedds#89)

Given how poorly it is documented and the indecision we've had (again see ros2/ros2#255), it doesn't surprise me that we have such an even split in implementations. But I will open issues on the latter two just so they're aware.

We did this to more closely emulate ROS 1's behavior (where published data was always just pushed onto a queue(s) which was processed separately, see https://github.com/ros/ros_comm/blob/d9059f49d14b7baf4a58c7759deab1f019681f5b/clients/roscpp/src/libros/publication.cpp#L407-L431). Also, many implementations require asynchronous publishing to handle large data (fragmentation).

For the above reasons I think it makes sense to stay with asynchronous publishing right now.

I could see a few paths in the future:

• we re-evaluate the above reasons and switch to synchronous always
• we re-evaluate the above reasons and decide to stick with async always
• we add an option in the ROS api allowing the user to pick and have a default (maybe async or not, maybe "smart" selection, e.g. see use a heuristic to determine whether or not to use asynchronous publishing rmw_connext#190)

In all of those cases we need to document the expected blocking behavior of the rmw_publish() function (and derived functions).

Personally I like the idea of adding an option to the ROS api in this case, but that's not likely to get back ported or be implemented very quickly. See also ros2/ros2#255

I would be happy to hear from others in the community and on the @ros2/team, to see if they agree or disagree with me.

[tfoote]

I agree that we should stick with asynchronous across all implementations for consistency between implementations as well as because it's what's expected of the ROS API. We were actually inconsistent between python and c++ originally in ROS 1 and converted python to asynchronous several years ago too.

From the comment on the Opensplice ticket it appears that it's also asynchronous and doesn't have support for synchronous publishing ros2/rmw_opensplice#301 (comment)

[MiguelCompany]

Closing this, as we already provided a way of avoiding async publishing on #470