Add arguments to configure number of threads

[wep21]

This PR enables to configure number of threads in component_container_mt as below.

    container = ComposableNodeContainer(
            name='my_container',
            namespace='',
            package='rclcpp_components',
            executable='component_container_mt',
            composable_node_descriptions=[component],
            output='screen',
            arguments=['-t', '5'],
    )

[fujitatomoya]

I am not really inclined to have this option. instead, how about providing documents how to support the custom component container? because this kind of extra option and arguments would be required and dependent on use cases?

[fujitatomoya]

CC: @clalancette @ivanpauno what would you think?

[wep21]

@fujitatomoya

this kind of extra option and arguments would be required and dependent on use cases?

I think it's better for component_container_mt to have the same option or arguments as MultiThreadedExecutor.

[ivanpauno]

Adding this options sounds reasonable to me.
It would also be great to provide a --help option.

[ivanpauno]

@wep21 could you add tests?

Maybe, you can move the function doing argument processing to anoter cpp file and unit test that.

[wjwwood]

Have we considered using ROS parameters to configure the number of threads instead (I'm slightly hesitant to add custom argument parsing)? The container is already a node (so that it can provide ROS Services). It's slightly more tedious on the command line, but from launch it should be somewhat straightforward (may require changes to ComposableNodeContainer, but I didn't check).

[wep21]

@wjwwood For current implementation, it is difficult to pass ros parameter to executor argument because ComponentManager node constructor obtains executor from argument.

[wjwwood]

@wjwwood For current implementation, it is difficult to pass ros parameter to executor argument because ComponentManager node constructor obtains executor from argument.

Interesting, but we could/maybe should change that. There's no strong reason that the executor is needed in the constructor as far as I know. It could be passed in via a method that is called after the constructor.

Also, we could look at the parameter overrides before creating the node to extract the setting, though the API to do so is a bit cumbersome if I remember correctly, but this is also an opportunity to fix that up while we do it.

Anyway, I still think custom argument parsing here is fragile and redundant.

[ivanpauno]

Using a parameter sounds fine to me 👍

[ivanpauno]

Replaced by #1708, closing