Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Proposal: Expose `is_data_valid` API for Loaned/Zero-Copy Messages

Aperta
  • Qualcosa non va?
#3,119 4 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

@kamal2730 ci sta già lavorando.

Dal 4/4/2026.

  • #874 di @kamal2730 — aperta
  • #3280 di @Aaravanand00 — aperta

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
35/100
Tipo di issue
Funzionalità
Chiarezza
Da chiarire
Stato di attività
Tranquilla
Stack tecnologico
cpp
Ambito
api, backend-api-design

Direzione di ricerca

Inizia leggendo le aree delle API rclcpp MessageInfo e Subscription, quindi confronta il pattern dell’interfaccia nativa di rmw_fastrtps_cpp menzionato nella proposta. Determina il confine previsto tra i controlli specifici del vendor, quelli generici di rmw e quelli di rclcpp rivolti all’utente; il lavoro è completato quando il comportamento dell’API è definito per i casi copiati, loaned validi, loaned invalidati e middleware non supportati.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

enhancement
Description

introduce an API at the rclcpp level that allows users to check whether loaned message memory is still valid (i.e., has not been overwritten by the middleware). this addresses a long-standing safety gap when using loaned messages and zero-copy transport with middleware implementations that reuse shared memory (e.g., Fast-DDS with data-sharing).

Motivation

when using loaned messages, especially with zero-copy pipelines over shared memory, the middleware may overwrite previously loaned memory under certain conditions:

  • the publisher and subscriber share a history cache in shared memory, so the publisher can cause changes in the subscriber's loaned memory even while the subscriber still holds a reference.
  • with PREALLOCATED_WITH_REALLOC memory policy, shared memory still in use may be reissued to new incoming samples.
  • the subscriber currently has no way to detect that its loaned data has been silently invalidated.

while loans were disabled in the executor as a short-term fix, the underlying problem remains for users who explicitly opt into loaned messages or zero-copy transports. currently, Fast-DDS provides an internal is_valid mechanism for data-sharing samples, but this is not exposed through any ROS 2 API layer.

Design / Implementation Considerations

the proposal approach is to add RMW Native Interface Pattern.

following the established pattern used by rmw_fastrtps_cpp to expose vendor-specific functionality (e.g., get_participant, get_subscriber, get_publisher), we propose a similar approach to expose data validity checks.

  • rmw_fastrtps (vendor-specific): rmw implementation that supports loaned messages with shared memory can expose a native validity check. middleware implementations that do not have this concern (e.g., Cyclone DDS, which allocates fresh memory) can either not implement this or always return true.
  • rmw interface (optional, generic): a generic function could be added to the rmw interface to allow middleware-agnostic checking. implementations that don't support or need this would return RMW_RET_UNSUPPORTED or set is_valid = true.
  • rclcpp (user-facing): expose the check through MessageInfo or the Subscription object so that users can query validity without reaching down to vendor-specific APIs like is_loaned_message_valid.
Scenario is_data_valid returns
Message was not loaned (normal copy) true (always safe)
Loaned message, memory still intact true
Loaned message, memory overwritten by publisher/pool false
Middleware does not support validity checking true (safe default)
Additional Information

several fixes have been applied or proposed (disabling loans, fixing the memory pool, returning loans via shared_ptr destructor).

  • zero-copy over shared memory inherently involves memory that the publisher can modify. this is by design in the DDS data-sharing model.
  • even with fixes to the executor and memory pool, advanced users opting into zero-copy need a mechanism to detect invalidation.
  • defense-in-depth: even if the middleware "should" not overwrite in-use memory, having a user-facing validity check provides a safety net.

in the original discussion, this check is inherently racy for true zero-copy over shared memory, memory could become invalid during a read. the is_data_valid API is therefore best suited as:

  • a post-read sanity check (read data, then verify it wasn't corrupted)
  • a debugging/diagnostic tool to identify when memory reuse issues occur
  • a guard before processing in non-real-time paths

it is not a substitute for proper loan lifetime management (returning loans via shared_ptr destructor, etc.).

Lingua principale
C++
Stelle
814
Fork
572
Merge medio
5g 3h
PR unite (30g)
17

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di ros2/rclcpp

Tutte le issue di ros2/rclcpp

Issue simili

Altre issue su C++

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.