Interest in real-time embedded support?

[Rkplanet]

Hello, love the project. Is there any thoughts of making this work in real time embedded systems? A lot of the main send/receive paths allocate heap memory via vec instantiations and so forth, and it seems the RTPS loops do as well. Would there be interest in optimizations there to only do heap allocation on startup?

[jhelovuo]

No, there is no such plan, and I do not know of any commercial interest in that.

What platform would have heap allocation available, but only at startup?

Making RustDDS work without (run-time) heap allocation would amount to a redesign rather than optimization. We need dynamic allocation because of the several unknowns:

• How many other DomainParticipants will there be? (1? or 200?)
• How many Topics are we going to see?
• How many DataReaders/DataWriters will the application create?
• How many remote Readers/Writers will our Writers/Readers match?
• Readers must keep track of received and missing samples. How to manage that?
• How long History buffers need to be maintained? (Depends on QoS setting from the application)
• What will be the maximum message rate for each topic?
• How large Samples will be transferred (with RTPS fragmentation, max sample size is 4 GiB)?
• How many and how large fragment reassembly buffers are needed?
• How many past Keys we need to remember to process Disposal via Key hash?
• etc.

It may be possible to resolve or limit some of these at compile time, or at startup, but it would be quite a large task. Most likely, some of the allocation would end up being handled with private memory pools, where a pool is allocated at startup, and run-time allocation is operating dynamically within the pool, much like an operating system manages physical memory pages.

Some of the bookkeeping could be avoided by supporting only stateless Readers and Writers, but that would also drop the ability to have QoS Reliability = Reliable. Stateful Readers are needed to implement that. (See the RTPS spec Section "8.4 Behaviour Module")

Overall, what you are suggesting seems like a large task, but please feel free to take it forward if you are interested. However, it is unlikely that such large changes would be accepted into RustDDS master branch, as they would add complexity and disrupt other work too much.

[Rkplanet]

Thank you for the detailed response. In a real time deterministic system there are requirements that bound the time an activity can take. Dynamically allocating memory is undeterministic because the OS has to find an unallocated segment of memory of the appropriate size, which could be found right away or only after scanning through much of the memory space. As the system runs and depending on what else the system is doing, the memory can get more and more fragmented such that later allocations take longer than early ones, messing up the determinism of the system. Such systems typically allocate "worst case" amounts (often config/use case driven) on initialization and then reuse them throughout the life of the program.

In an environment like this there are things that wouldn't be expected to happen "randomly" like a new DomainParticipant joining the system, so I'd expect allocating for that would be fine. But specifically along the send/receive paths new allocations would cause problems there.

I know there are implementations of DDS written for embedded/real time environments (not in Rust) so I wasn't sure if you had put any thought into usage in that domain or not. Maybe the simplest way would be to allow the user to set an allocator and tie it to their own memory pool which can probably be done already by setting the Rust allocator. But that would only work if the allocation sizes were patterned in certain ways and somewhat known, which doesn't sound like the case.

Thanks again for the details and great work on the implementation.