rclcpp::detail::PendingList Struct Reference

#include <future.hpp>

Collaboration diagram for rclcpp::detail::PendingList:

Public Member Functions
bool	can_send () const
size_t	count () const
void	deliver (PendingLink *owner, const uint8_t *data, size_t len)
	Hand a reply to owner, which is answered and leaves the list.
void	link (PendingLink *l)
void	move_to (PendingList &to, void *storage)
void	orphan_all ()
size_t	prune ()
void	relink (PendingLink *from, PendingLink *to)
	A moved future: the list must point at its new address.
bool	remove_seq (int64_t seq)
PendingLink *	resolve (int64_t seq)
PendingLink *	resolve_goal (const uint8_t goal[16])
bool	unlink (PendingLink *l, bool abandoned)

Public Attributes
void(*	forget )(void *ctx, const uint8_t goal[16]) = nullptr
void *	forget_ctx = nullptr
PendingLink *	head = nullptr
uint8_t	orphans = 0

Detailed Description

Issue 2009 — the requests ONE poll client has in flight, as an intrusive list of the futures waiting on them, each keyed by its request's sequence id. A reply is delivered only to the future whose id it carries; a reply naming no pending future (a removed or destroyed one's) is dropped.

The same rule as Rust's nros_rmw::RequestCorrelator, which every other client surface uses. It lives in the futures here rather than in a table because each future already owns the buffer its reply must land in.

BOUNDED, NO HEAP, NO CAPACITY TO MIS-SIZE: an entry is a future the caller already holds, so the list is as long as the futures in flight. What caps that is the transport's own outstanding-request limit (zenoh NROS_ZENOH_MAX_PENDING_GETS, Cyclone's 8 per client): a send past it is refused by the backend, and send_request then returns an empty future (valid() false) without linking anything.

A backend that cannot assign ids (SEQUENCE_ID_UNKNOWN) gets one request in flight per client — can_send() refuses a second while the first is pending — and an unkeyed reply goes to the sole pending future. A removed unkeyed request costs the next unkeyed reply (orphans), which is dropped rather than delivered to a newer request it cannot be told apart from.

Member Function Documentation

can_send()

bool rclcpp::detail::PendingList::can_send ( ) const

inline

count()

size_t rclcpp::detail::PendingList::count ( ) const

inline

deliver()

void rclcpp::detail::PendingList::deliver ( PendingLink * owner, const uint8_t * data, size_t len )

inline

Hand a reply to owner, which is answered and leaves the list.

link()

void rclcpp::detail::PendingList::link ( PendingLink * l )

inline

move_to()

void rclcpp::detail::PendingList::move_to ( PendingList & to, void * storage )

inline

The poll client that owns this list MOVED to to (whose storage is storage): every pending future follows it.

orphan_all()

void rclcpp::detail::PendingList::orphan_all ( )

inline

The poll client that owns this list is going away: every pending future becomes invalid (valid() false) instead of pointing at freed storage.

prune()

size_t rclcpp::detail::PendingList::prune ( )

inline

Forget every pending request, as remove_pending_request does for one: each waiting future becomes invalid and its reply, if it still comes, is dropped. Returns how many were pending.

relink()

void rclcpp::detail::PendingList::relink ( PendingLink * from, PendingLink * to )

inline

A moved future: the list must point at its new address.

remove_seq()

bool rclcpp::detail::PendingList::remove_seq ( int64_t seq )

inline

Issue 2037 — forget the pending request whose sequence id is seq, as remove_pending_request(request_id) does upstream: its future becomes invalid and its reply, if it still comes, is dropped. False when no request with that id is pending (answered, removed, or another client's). SEQUENCE_ID_UNKNOWN names nothing.

resolve()

PendingLink * rclcpp::detail::PendingList::resolve ( int64_t seq )

inline

The pending future a reply carrying seq answers, or nullptr (stale: drop it). Does not unlink.

resolve_goal()

PendingLink * rclcpp::detail::PendingList::resolve_goal ( const uint8_t goal[16] )

inline

Issue 2011 — the pending ACTION future waiting on goal, or nullptr (nobody waits: the reply is dropped, never handed to another goal's future). Exact match only; does not unlink.

unlink()

bool rclcpp::detail::PendingList::unlink ( PendingLink * l, bool abandoned )

inline

Unlink l if present. abandoned: its request will never be taken through it (removed / destroyed), as opposed to answered.

Member Data Documentation

forget

void(* rclcpp::detail::PendingList::forget) (void *ctx, const uint8_t goal[16]) = nullptr

Issue 2027 — what the OWNER of this list does when a goal-keyed future is abandoned (cancelled, destroyed, moved over) before its reply: the action client frees the request's slot in the Rust core unless something else still waits on that reply. Null for a service client's list, whose requests hold no slot here (the transport's own limit bounds them, and an abandoned one costs nothing once it times out).

forget_ctx

void* rclcpp::detail::PendingList::forget_ctx = nullptr

head

PendingLink* rclcpp::detail::PendingList::head = nullptr

orphans

uint8_t rclcpp::detail::PendingList::orphans = 0

---

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

• include/rclcpp/future.hpp