Fixes for intra-process actions

[mauropasse]

Fixes for intra-process actions:

• Don't throw in a normal situation of expired IPC Action client
• Check if data in buffers before extract
• Fix IPC Actions QoS depth
• Fix data race on IPC Actions callbacks
• Correct intra-process actions is_ready()
• Use Goal ID as key to store client callbacks and responses from server
• Use the FNV-1a hash algorithm for Goal UUID
• Remove RCL_RET_CLIENT_TAKE_FAILED error log - add comment instead

The following (simplified) flowchart represents what's happening when the Action Client sends a goal request go the Action Server, until the server accepts and responds to the client:

auto goal_handle_future = action_client->async_send_goal(goal_msg, send_goal_options);
auto goal_handle = goal_handle_future.get();

The process is almost exactly the same for:

auto result_future = action_client->async_get_result(goal_handle);
auto wrapped_result = result_future.get();

and for cancel:

    auto cancel_result_future = action_client->async_cancel_goal(goal_handle);
    auto cancel_result = cancel_result_future.get();

In the following chart I show part of action_client->async_get_result but focusing on the server logic, which sends the result only if the client has requested for it:

[alsora]

why these are removed?

[mauropasse]

Setting the flag here was breaking the SingleThreadedExecutor, which already sets the is_*_ready_ flags on the is_ready() API.
For EventsExecutor, the flags are set on the take_data_by_entity_id() API.

[mauropasse]

Some comments about how things work, I'll try to make it simple and not very long. (see new flowchart in comment below)

Every time the Client requests something to the Server, a callback is created: it will be called when the server sends back the response (using the response as argument).
After the callback is called, must be removed (in some cases), since they maintain in scope shared pointers.

We have 5 types of Action Client events (EventType), all of them with their ResponseCallback callback:

• FeedbackSubscription -> Callback created on client constructor - no need to remove after call
• StatusSubscription -> Callback created on client constructor - no need to remove after call.

For every individual goal sent we have:

• GoalClient -> Callback created when async_send_goal - must be removed after call
• ResultClient -> Callback created when async_get_result - must be removed after call
• CancelClient -> Callback created when async_cancel_goal - must be removed after call

Since a client can make multiple requests, we need a storage for all the individual goal IDs, event types, their callbacks, and the unread_count.

I created a structure to hold all the info and data to process the different events, mapped with their respective "Goal ID". So we have in the map:

< Goal_ID, {EventType, ResponseCallback, unread_count} >

Besides this map, we have all the IPC ring-buffers to hold the responses from the server. They look like:

<Goal_ID, ServerResponse>

So when we extract an element (response) form the ring buffer, we get the Goal_ID and use it as key to extract the ResponseCallback and call it (and then remove it, if necessary).

[bpwilcox]

For a simple interaction client/server, there are usually 4 threads involved. That's an extra complication that required attention avoiding races

Could you elaborate which threads are involved and what each are doing for a client/server interaction?

[mauropasse]

Could you elaborate which threads are involved and what each are doing for a client/server interaction?

The threads involved are:

1. Client app thread sending goal requests
2. Client executor thread (sets the "on_ready_callback" and executes action client work)
3. Server executor thread (puts responses into the client's ring buffers)
4. Server thread (usually created to execute the goal, also puts responses into the client's ring buffers)

[bpwilcox]

In this ipc function I still see calls to rcl such as rcl_action_get_zero_initialized_goal_info(). What is the goal_info? How is this relevant or necessary to call into rcl when going through ipc?

[mauropasse]

In this case, the rcl_action_goal_info_t goal_info is just used to obtain the rcl_goal_handle, to then update the goal state.
The "bookkeeping" of the goal state is still performed in rcl.

[bpwilcox]

Similar question to my other comment, but why do we need to get cancel_request from rcl layer while doing ipc? I know this PR is built on top of previous work but I am missing the rationale for the interaction with the rcl layer.

[mauropasse]

Only the communication (send request / responses / etc) goes through intra-process.
But the rest of the logic still lives in rcl, that is, we still use the rcl_handle which controls the goal state, etc.

In summary, all the rcl_action_send_* have their parallel intra_process_action_send_* versions. But the rest of the code is common.