Module listener 

Listener-Hierarchie (DDS DCPS 1.4 §2.2.4.2 + §2.2.2.*.3 set_listener).

Listener sind asynchrone Notification-Hooks, die der Middleware- Layer aufruft, sobald sich ein Communication-Status ändert. Pro Entity-Typ gibt es einen Listener-Trait mit einem Callback je relevantem Status:

DomainParticipantListener   (13 Callbacks — alle Bubble-Up-Targets)
├── PublisherListener       (4  Callbacks — Writer-bezogen)
│   └── DataWriterListener  (4  Callbacks)
├── SubscriberListener      (8  Callbacks — Reader + on_data_on_readers)
│   └── DataReaderListener  (7  Callbacks — Reader-spezifisch)
└── TopicListener           (1  Callback — on_inconsistent_topic)

Bubble-Up (Spec §2.2.4.2.3)

Wenn auf der “kleinsten” Entity (z.B. DataReader) kein Listener gesetzt ist (oder der Listener das Status-Bit nicht in seiner Mask hat), bubblet das Event nach oben zur nächst-grösseren Entity: Reader → Subscriber → Participant. Analog Writer → Publisher → Participant. Topic-Events bubbeln direkt zum Participant. Die bubble_up_consumed-Helfer in listener_dispatch kapseln diese Resolution.

Object-Safety

Alle 6 Traits sind object-safe (keine Self-Returns, keine Generics, keine assoziierten Typen). Damit der jeweilige Trait generisch über T: DdsType einsetzbar ist (wir haben Topic<T>, DataWriter<T>, DataReader<T>), übergeben wir den Entity-Handle als opaken InstanceHandle — analog zum DDS-DCPS-IDL-PSM, das Listener-Callbacks ebenfalls nur den Entity-Handle gibt (DCPS 1.4 §2.3.3 IDL).

Wir speichern den Listener als Box<dyn ListenerTrait + Send + Sync> im Entity-State, damit er Cross-Thread sichtbar ist (Spec sagt nicht, dass Listener-Callbacks aus dem Application-Thread laufen müssen).

Alle Methoden haben &self (nicht &mut self), weil der Listener im hot path geteilt wird; der Callback-Body muss interior mutability verwenden, falls er State führt.

Default-Impls

Jede Methode hat ein Empty-Body. Anwender überschreiben nur die Callbacks, die sie wirklich brauchen.

Traits

DataReaderListener

DataReaderListener — Spec §2.2.2.5.7 + §2.2.4.2.6.

DataWriterListener

DataWriterListener — Spec §2.2.2.4.4 + §2.2.4.2.4.

DomainParticipantListener

DomainParticipantListener — Spec §2.2.2.2.3 + §2.2.4.2.8.

PublisherListener

PublisherListener — Spec §2.2.2.4.3.

SubscriberListener

SubscriberListener — Spec §2.2.2.5.6 + §2.2.4.2.7.

TopicListener

TopicListener — Spec §2.2.2.3.2 + §2.2.4.2.5.

Functions

listener_handles

True wenn mask das Bit für status setzt und der Listener nicht-None ist. Diese Kombi entscheidet, ob ein Event auf der aktuellen Stufe konsumiert wird (Spec §2.2.4.2.3).

status_bit_for_inconsistent_topic

Vorab-Hilfsfunktion: liefert den Status-Bit-Wert zu einem Status-Namen. Nur in Tests + Doku-Beispielen verwendet — Hot-Path nutzt direkt die Konstanten in crate::psm_constants::status.

Type Aliases

ArcDataReaderListener

Vgl. ArcTopicListener.

ArcDataWriterListener

Vgl. ArcTopicListener.

ArcDomainParticipantListener

Vgl. ArcTopicListener.

ArcPublisherListener

Vgl. ArcTopicListener.

ArcSubscriberListener

Vgl. ArcTopicListener.

ArcTopicListener

Arc-Variante fuer per Slot speichern wir den Listener als Arc<dyn ...>, weil der Hot-Path den Listener kurz unter dem Slot-Mutex klont und dann ausserhalb des Locks ruft (Deadlock- Vermeidung). Box wuerde das nicht zulassen.

BoxedDataReaderListener

Vgl. BoxedTopicListener.

BoxedDataWriterListener

Vgl. BoxedTopicListener.

BoxedDomainParticipantListener

Vgl. BoxedTopicListener.

BoxedPublisherListener

Vgl. BoxedTopicListener.

BoxedSubscriberListener

Vgl. BoxedTopicListener.

BoxedTopicListener

Heap-allokierter, threadsicherer Box-Wrapper für die 6 Listener-Traits. So speichert die jeweilige Entity ihren Listener.