Using Librclc Needs Header Files

[PatrickHaecker]

If you use a language like C or C++ which uses the header files, rclc can obviously be used. However, for other programming languages which are able to use libraries, but are not C-compatible, the library file alone is not enough to use rclc.

This is mostly, because the current design expects stack allocated data structures of the correct size when calling rclc functions and partly because some defines are needed. The data structures are only managed by the caller and the caller does not need to introspect them beyond calling rclc functions.

Thus, rclc's API should be extended to do heap allocation itself, if explicitly requested, and to provide the define values during runtime to enable this use case.

The proposal is implemented in #404

[Zard-C]

Thus, rclc's API should be extended to do heap allocation itself, if explicitly requested, and to provide the define values during runtime to enable this use case.

Considering the real-time requirements, the design philosophy of the rclc library is to minimize runtime dynamic memory allocation as much as possible. Therefore, many data structures are pre-allocated with fixed sizes. The proposed solution seems to violate this design philosophy.

Some examples can be found in https://github.com/ros-realtime/roscon-2023-realtime-workshop/blob/main/Realtime%20workshop%20ROScon%202023.pdf

[PatrickHaecker]

Thanks for having a look at the proposal.

Considering the real-time requirements, the design philosophy of the rclc library is to minimize runtime dynamic memory allocation as much as possible. Therefore, many data structures are pre-allocated with fixed sizes. The proposed solution seems to violate this design philosophy.

Let me explain this in more detail: The proposed solution does indeed do memory allocations at runtime, as you rightfully point out. However, the allocations are only done before starting to spin. It uses the following mental model to split the program into three phases.

1. The non-realtime initialization phase
2. The realtime spinning phase
3. The (possibly) non-realtime cleanup/freeing phase

To my understanding that's how rclc is already implemented and therefore in line with rclc's design philosophy.

Does it make the initialization phase even "less realtime"? Yes, because of adding additional allocations.
Does it affect existing uses? No, because this is an additional interface which can be used for those who see a benefit in using the new interface. The old stack-based interface will not go away by providing an additional heap-based one.

[Zard-C]

Does it make the the initialization phase even "less realtime"? Yes, because of adding additional allocations.
Does it affect existing uses? No, because this is an additional interface which can be used for those who see a benefit in using the new interface. The old stack-based interface will not go away by providing an additional heap-based one.

Thanks for your proposal and the detailed explanation. I appreciate you taking the time to address the real-time requirements and the design philosophy of the rclc library.

It's good to know that the new heap-based interface is optional and won't impact existing users who prefer the stack-based interface. This added flexibility could be beneficial for those who need it.

Thanks again for your insights and thorough explanation.