Fix topic creation race condition

[ivanpauno]

We were checking if the topic was already creating and then creating it if not.
There's a TOCTTOU race condition here.

To avoid the problem, I've added a mutex for each participant, and locking it when creating a topic.

The race condition could be experienced when launching gazebo:

ros2 launch gazebo_ros gzserver.launch.py

though it was extremely hard to reproduce (I was never able to reproduce it, but @jacobperron was able to).

The failure looked like:

• publisher failing

    [gzserver-1] terminate called after throwing an instance of 'rclcpp::exceptions::RCLError'
    [gzserver-1]   what():  could not create publisher: failed to create topic '/clock' for node namespace='/' name='gazebo', at /home/jacob/ws/ros/gazebo_ros/src/ros2/rmw_connext/rmw_connext_cpp/src/rmw_publisher.cpp:208, at /home/jacob/ws/ros/gazebo_ros/src/ros2/rcl/rcl/src/rcl/publisher.c:172
    [gzserver-1] Aborted (core dumped)

• subscription failing

[gzserver-1] terminate called after throwing an instance of 'rclcpp::exceptions::RCLError'
[gzserver-1]   what():  could not create subscription: failed to create topic '/clock' for node namespace='/' name='gazebo', at /home/jacob/ws/ros/gazebo_ros/src/ros2/rmw_connext/rmw_connext_cpp/src/rmw_subscription.cpp:202, at /home/jacob/ws/ros/gazebo_ros/src/ros2/rcl/rcl/src/rcl/subscription.c:168

I haven't confirmed that gazebo is trying to create the publisher and subscription from different threads, but it sounds like that was the case.

[ivanpauno]

I was curious if there was a similar race condition for services and clients.
That code lives here and here, and there doesn't seem to be any race condition in that case 😃 .

[ivanpauno]

@ros-pull-request-builder retest this please

[ivanpauno]

• Linux
• macOS
• Windows

[jacobperron]

This appears to have fixed the issue for me 👍

[clalancette]

I think we need this same fix in the dynamic version of the code as well:

rmw_connext/rmw_connext_dynamic_cpp/src/functions.cpp

Line 497 in da982d1

topic_description = participant->lookup_topicdescription(topic_str);

and

rmw_connext/rmw_connext_dynamic_cpp/src/functions.cpp

Line 497 in da982d1

topic_description = participant->lookup_topicdescription(topic_str);

I know we don't really build or test it, but since we are in here fixing this we may as well do the same there.

[ivanpauno]

I think we need this same fix in the dynamic version of the code as well:

Done in 79aa945.

I really don't think we should continue updating rmw_connext_dynamic, it is extremely outdated.

IMO, if we want to support it again, it will be easier to rewrite than update it (the only piece of useful code there is how to create a DDS type code from a ROS typesupport and how to convert between ROS and DDS messages with the introspection typesupport).

[clalancette]

I really don't think we should continue updating rmw_connext_dynamic, it is extremely outdated.

IMO, if we want to support it again, it will be easier to rewrite than update it (the only piece of useful code there is how to create a DDS type code from a ROS typesupport and how to convert between ROS and DDS messages with the introspection typesupport).

Yeah, I basically agree here. Personally I'd just remove the code from the repository altogether. If anyone wants to revive it, it would be in git history to serve as a starting point. I'll bring it up at the next meeting.

[clalancette]

Looks good to me. I'll suggest letting @jacobperron take one more look at it before merging.

[jacobperron]

LGTM

[jacobperron]

This change (and the follow-up fix in #444) are not ABI compatible due to changes to publicly accessible structs. I'm not sure of a nice way to make them backwards compatible so I'm removing from the Foxy board.