Add get_non_local_subscription_count to PublisherBase

[MiguelCompany]

Adds a method in PublisherBase that returns the number of matched subscriptions that are not in the same context as the publisher.

It also makes inter-process publishing depend on this new method.

Depends on ros2/rcl#1111

Part of #2202

full repos file here

[alsora]

Can we add a couple of unit-tests?

[fujitatomoya]

I think this means that Not in the same context for the ROS 2 user (precisely for DDS-RTPS, GUID prefix is not the same), that would be nicer to add the description explains?

[fujitatomoya]

Suggested change

	"failed to get get non local subscription count");
	"failed to get non local subscription count");

[sloretz]

@MiguelCompany Friendly ping. Would you be willing to address @fujitatomoya's feedback?

[mauropasse]

I've been testing the new feature enabled by:

bool inter_process_publish_needed = get_non_local_subscription_count() > 0;

This not only fixes the "double delivery" issue (local subscription receiving intra & inter process message), but also reduces CPU at startup and destruction of subscriptions.

When creating a subscription, there is a short time gap in which the intra-process subscription has not yet been created, so messages come through inter-process (serialization/deserialization/etc) causing high CPU utillization.
The same happens when the subscription is destroyed, since first the intra-process subscription is destroyed, it'll receive messages through the DDS until the whole subscription is destroyed.

This is particularly noticeable for /parameter_events built in subscriptions: in a big system with many nodes using parameters, these subscriptions might receive thousands of inter-process messages at startup.

[mauropasse]

Correction about my statement above:

This not only fixes the "double delivery" issue..

This PR doesn't fix the double delivery issue. It does avoid getting inter-process messages at creation/destruction of subscriptions.

Is there anything missing to avoid the double delivery issue @MiguelCompany ? Or is that a separate effort?

• Process1: Sub_1 --> /topic <-- Pub
• Process2: Sub_2 --> /topic
• Issue: Sub_1 receives both inter and intra-process messages