Has a CPU shared-memory backend for rosidl::Buffer been explored?

I have been looking into rosidl::Buffer and the current buffer backend support, particularly for large variable-length payloads such as images and point clouds.

One idea I am interested in is a CPU shared-memory backend for rosidl::Buffer.

I realize that this overlaps to some extent with functionality that already exists at lower layers. For example, some middleware / RMW implementations already provide shared-memory transport or other zero-copy optimizations. Depending on the implementation, moving data through shared memory may therefore already be possible without introducing a dedicated Buffer backend.

What I am trying to understand is whether there is still a useful role for shared memory at the rosidl::Buffer layer.

My interest is specifically in large variable-length fields where avoiding copies of the payload itself is useful. Rather than treating shared memory only as a transport optimization for a serialized message, a Buffer backend could potentially make the payload storage itself shared and let a buffer-aware RMW transport a descriptor or reference when appropriate.

Conceptually:

ROS message
  metadata
  rosidl::Buffer<uint8_t>
          |
          +-- CPU shared-memory backend
                  |
                  +-- shared payload storage

This seems potentially complementary to transport-level shared memory rather than necessarily a replacement for it. On the other hand, I can also imagine that the overlap with middleware-native SHM mechanisms may be a reason why such a backend has not been pursued.

In particular, I would be interested in hearing:

  • Has anyone already explored a CPU shared-memory backend for rosidl::Buffer?
  • Is sharing the backing storage of large variable-length payloads considered an intended use of the Buffer backend abstraction?

Before prototyping something in this direction, I wanted to check whether there is already related work or design discussion that I have missed. I previously explored a similar problem for CUDA IPC in this discussion, so I would especially like to avoid independently reimplementing something that is already being worked on elsewhere.

Related links

4 Likes

(post deleted by author)

Have you answered to the correct topic? I don’t see how is your answer relevant to this one…

1 Like