nros rmw-cffi
C vtable for plugging a third-party RMW backend into nros
Loading...
Searching...
No Matches
Data Fields
rmw_message_info_t Struct Reference

#include <rmw_entity.h>

Collaboration diagram for rmw_message_info_t:
Collaboration graph
[legend]

Data Fields

bool from_intra_process
 
uint64_t publication_sequence_number
 
rmw_gid_t publisher_gid
 
rmw_time_point_value_t received_timestamp
 
uint64_t reception_sequence_number
 
rmw_time_point_value_t source_timestamp
 

Detailed Description

Per-sample metadata — upstream rmw_message_info_t, field for field.

Phase 376 W4. Today this metadata reaches Rust callers through MESSAGE_INFO_TABLE, a side table in nros-rmw-cffi keyed on the subscription's backend_data ADDRESS. That table is a workaround, not a design, and it never crosses the seam it exists for: only the Rust trampoline writes it, so a C or C++ backend has no symbol to call and message info is permanently absent for them. It also claims a pool slot per subscription and never releases it, so a reused handle address inherits the previous subscription's metadata.

Passing the struct by pointer on the take call — which is what upstream does — removes all of that: the caller owns the storage, it lives exactly as long as the call, and every backend can fill it.

Retiring the side table is NOT part of this change; the take_with_info slots are the mechanism that makes retiring it possible.

Field Documentation

◆ from_intra_process

bool rmw_message_info_t::from_intra_process

True when the sample never left the image (Zephyr's Z_FEATURE_LOCAL_SUBSCRIBER, DDS intra-process).

◆ publication_sequence_number

uint64_t rmw_message_info_t::publication_sequence_number

Publisher-side sequence, or RMW_MESSAGE_INFO_SEQUENCE_NUMBER_UNSUPPORTED. Whether this is real is what feature_supported answers.

◆ publisher_gid

rmw_gid_t rmw_message_info_t::publisher_gid

Which publisher sent it. All-zero data = unknown.

◆ received_timestamp

rmw_time_point_value_t rmw_message_info_t::received_timestamp

Subscriber's clock at reception, ns. 0 = receptions are not stamped.

◆ reception_sequence_number

uint64_t rmw_message_info_t::reception_sequence_number

Subscriber-side reception count, or the same sentinel.

◆ source_timestamp

rmw_time_point_value_t rmw_message_info_t::source_timestamp

Publisher's clock at publication, ns. 0 = no source timestamp.


The documentation for this struct was generated from the following file: