Shared Memory

← Back to overview

The pain

Same-host transport should be the easy, fast case — two processes on one machine exchanging data through shared memory. In DDS practice it is one of the largest failure surfaces (52 reports): segfaults, /dev/shm exhaustion, cross-user permission failures, mutex-timeout races on init, and the fixed-size-pool model (Iceoryx) that does not fit variable-size robotics data.

  • Variable-size types deliver zero samples and pin a CPU core at 100 % over the Iceoryx PSMX path — the fixed-pool model fights point clouds and images.
  • Data-sharing readers can loop forever during shared-segment init.
  • SHM files get the wrong permissions (umask), blocking cross-user access.
  • Init races produce mutex-timeout failures and spurious “segment may be insufficient” warnings.

Most recent example

rmw_cyclonedds#585 — “Variable-size types deliver zero samples over PSMX (iceoryx) and pin a core at 100 % CPU” (2026-06-02). The shared-memory fast path delivers nothing for variable-size types while burning a full core — the exact mismatch between a fixed-size SHM pool and variable-size robotics payloads.

Reference list (most recent)

Date Source Problem
2026-06-02 rmw_cyclonedds#585 Variable-size types → 0 samples + 100 % CPU over iceoryx
2026-03-21 Fast-DDS#6338 Data-sharing reader loops forever in segment init
2025-12-02 Fast-DDS#6206 Spurious “segment_size may be insufficient” warning
2025-11-10 Fast-DDS#6162 umask wrong on SHM files → cross-user access blocked
2025-10-22 Fast-DDS#6117 SHM init_port mutex-timeout race

How ZeroDDS solves it

A variable-size, length-prefixed SHM ring — and a safe core that cannot segfault.

  • Variable-size by design. ZeroDDS’s shared-memory transport is a length-prefixed ring, not a fixed-size pool. Variable-size payloads (point clouds, images) flow without a hand-dimensioned pool, so the #585 “fixed pool delivers zero variable-size samples” failure does not arise. The single size knob, ZERODDS_SHM_MAX_DATAGRAM, sizes the ring; capacity tracks it automatically.
  • No segfault class. The SHM path is built in Rust; the safe core is forbid(unsafe_code) and the small unsafe mmap/flock surface is isolated and audited. The buffer-overrun and use-after-free segfaults reported against C++ SHM transports are not expressible in the safe data path.
  • No busy-wait, no init-race livelock. Wait paths are event-driven (condvar/notify), not spin loops, so the “loops forever pinning a core” and “mutex-timeout init race” failure modes are designed out.
  • Cross-process correctness. Atomics over shared memory with well-defined cross-process semantics; a crash-recovery cleanup path handles a dead owner.

Why it no longer has to be a pain

The SHM cluster is fixed-size pools vs variable robotics data plus unsafe C++ plumbing that segfaults and live-locks. ZeroDDS uses a variable-size ring and a memory-safe implementation with event-driven waits — so same-host zero-copy is the fast path it was supposed to be, for the payloads robotics actually sends.

Reproduce it yourself

# Same-host SHM path with a large variable-size sample:
cargo test -p zerodds-transport-shm
# (and the largedata examples with the same-host-shm feature)

→ Back to overview · Next: Scaling

Shared Memory

← Zurück zur Übersicht

Der Schmerz

Same-Host-Transport sollte der einfache, schnelle Fall sein — zwei Prozesse auf einer Maschine, die Daten über Shared Memory austauschen. In der DDS-Praxis ist es eine der größten Fehler-Oberflächen (52 Reports): Segfaults, /dev/shm-Erschöpfung, Cross-User-Permission-Fehler, Mutex-Timeout-Races beim Init und das Fixed-Size-Pool-Modell (Iceoryx), das nicht zu variabel-großen Robotik-Daten passt.

  • Variabel-große Typen liefern null Samples und pinnen einen CPU-Kern auf 100 % über den Iceoryx-PSMX-Pfad — das Fixed-Pool-Modell kämpft gegen Punktwolken und Bilder.
  • Data-Sharing-Reader können bei der Shared-Segment-Init ewig loopen.
  • SHM-Files bekommen die falschen Permissions (umask) und blockieren Cross-User-Zugriff.
  • Init-Races erzeugen Mutex-Timeout-Fehler und falsche „segment may be insufficient”-Warnungen.

Jüngstes Beispiel

rmw_cyclonedds#585 — „Variable-size types deliver zero samples over PSMX (iceoryx) and pin a core at 100 % CPU” (2026-06-02). Der Shared-Memory-Fast-Path liefert für variabel-große Typen nichts und verbrennt dabei einen vollen Kern — genau der Mismatch zwischen einem Fixed-Size-SHM-Pool und variabel-großen Robotik-Payloads.

Referenzliste (jüngste zuerst)

Datum Quelle Problem
2026-06-02 rmw_cyclonedds#585 Variabel-große Typen → 0 Samples + 100 % CPU über Iceoryx
2026-03-21 Fast-DDS#6338 Data-Sharing-Reader loopt ewig in der Segment-Init
2025-12-02 Fast-DDS#6206 Falsche „segment_size may be insufficient”-Warnung
2025-11-10 Fast-DDS#6162 umask falsch auf SHM-Files → Cross-User-Zugriff blockiert
2025-10-22 Fast-DDS#6117 SHM-init_port-Mutex-Timeout-Race

Wie ZeroDDS es löst

Ein variabel-großer, längen-präfixierter SHM-Ring — und ein sicherer Kern, der nicht segfaulten kann.

  • Variabel-groß by design. Der Shared-Memory-Transport von ZeroDDS ist ein längen-präfixierter Ring, kein Fixed-Size-Pool. Variabel-große Payloads (Punktwolken, Bilder) fließen ohne hand-dimensionierten Pool, sodass der #585-Fehler „Fixed-Pool liefert null variabel-große Samples” nicht entsteht. Der einzige Größen-Knopf, ZERODDS_SHM_MAX_DATAGRAM, dimensioniert den Ring; die Kapazität folgt automatisch.
  • Keine Segfault-Klasse. Der SHM-Pfad ist in Rust gebaut; der sichere Kern ist forbid(unsafe_code), und die kleine unsafe-mmap/flock-Oberfläche ist isoliert und auditiert. Die Buffer-Overrun- und Use-after-free-Segfaults, die gegen C++-SHM-Transporte gemeldet werden, sind im sicheren Daten-Pfad nicht ausdrückbar.
  • Kein Busy-Wait, kein Init-Race-Livelock. Warte-Pfade sind event-getrieben (Condvar/Notify), keine Spinloops, sodass die Fehlermodi „loopt ewig und pinnt einen Kern” und „Mutex-Timeout-Init-Race” wegdesignt sind.
  • Cross-Process-Korrektheit. Atomics über Shared Memory mit wohldefinierter Cross-Process-Semantik; ein Crash-Recovery-Cleanup-Pfad behandelt einen toten Owner.

Warum es kein Schmerz mehr sein muss

Der SHM-Cluster ist Fixed-Size-Pools vs variable Robotik-Daten plus unsicheres C++-Plumbing, das segfaultet und live-lockt. ZeroDDS nutzt einen variabel-großen Ring und eine memory-safe Implementierung mit event-getriebenen Waits — sodass Same-Host-Zero-Copy der schnelle Pfad ist, der es sein sollte, für die Payloads, die Robotik tatsächlich sendet.

Selbst reproduzieren

# Same-Host-SHM-Pfad mit einem großen variabel-großen Sample:
cargo test -p zerodds-transport-shm
# (und die largedata-Examples mit dem same-host-shm-Feature)

→ Zurück zur Übersicht · Weiter: Scaling