Add thing which adds things to wait set

[sloretz]

Feature request

This is a request for a feature to allow waiting on action servers and action clients. Action servers and Action clients are to be implemented in libraries on top of the core rcl and rclcpp features in rcl_action and rclcpp_action. Adding them to the wait set in rcl is covered by ros2/rcl#335.

Feature description

This feature would allow an executor to wait on action servers and action clients which have servers/timers/clients/subscribers created in C. Since the individual entities don't have rclcpp::<Entity>Base types they can't be used by the existing callback group and executor APIs.

With #519 in mind it could make sense to change callback groups to be the class that adds things to the wait set, but I don't think there is time before the Crystal release. Instead this feature is proposing to add a new class to be used along with callback groups.

Implementation considerations

Assuming class called Waitable with virtual APIs

• virtual get_number_of_entities(size_t * num_subscriptions, ...)
  • Called by executor when determining how big to allocate the wait set
• virtual void add_to_wait_set(rcl_wait_set_t *)
  • Called by executor when populating the wait set
  • Because get_number_of_entities() and add_to_wait_set() are separate calls, it must be assumed that the number of entities in a Waitable are constant between the two calls. For actions this assumption holds because the number of waitable entities is constant for the life of the server and client.
• virtual bool can_execute(rcl_wait_set_t *)
  • Return true if there is something that can be executed in the waitset.
• virtual void execute();
  • It's assumed the waitable will set some state within itself during can_execute() so that it does the right thing here.

Using Waitable requires:

• Adding a Waitable::SharedPtr field to AnyExecutable
• Executor::execute_any_executable() needs to call Waitable::execute()
• Adding API add_waitable(Waitable::SharedPtr) to Node, possibly via NodeWaitableInterface (and an API to remove them)
• MemoryStrategy needs api number_of_ready_waitables()
• AllocatorMemoryStrategy::add_handles_to_wait_set() needs to give Waitable a chance to add things
• MemoryStrategy needs api get_next_waitable() to be used by Executor::get_next_executable

Requires ros2/rcl#335 so Executor and Waitable can know which entities belong to which.

[wjwwood]

This makes sense to me, I had imagined a "Waitable" concept from early days, but didn't have time to implement it.

Thanks for writing it down so clearly :)

[jacobperron]

👍

Correct me if I'm wrong. Specifically, can_execute(rcl_wait_set_t *) should return true if the Waitable has some internal entities that can execute in the wait set (not necessary any entity in the wait set).

[ros-discourse]

This issue has been mentioned on ROS Discourse. There might be relevant details there:

https://discourse.ros.org/t/the-design-of-waitable/19136/3