Sam Daniel via Xenomai <[email protected]> writes:
> On Tue, Jan 26, 2021 at 10:07 AM Jan Kiszka <[email protected]> wrote: > >> On 25.01.21 22:07, Sam Daniel via Xenomai wrote: >> > On Mon, Jan 25, 2021 at 12:20 PM Sam Daniel < >> [email protected]> >> > wrote: >> > >> >> Is it possible to look up from userspace code all of the IDDP/XDDP >> labels >> >> that exist in the registry without leaving the primary domain? >> >> >> >> I have tried a few different ways of reading the contents of >> >> /proc/xenomai/registry/rtipc/iddp. The inotify API causes mode switches >> (it >> >> relies on select or poll), not to mention that inotify does not work >> well >> >> with virtual filesystems. And using the C++ filesystem library to read >> the >> >> contents of the directory also causes mode switches (filesystem >> >> interactions). >> >> >> >> Is there a real-time API function that I can use to query these labels? >> >> >> > >> > C++ filesystem library is causing mode switches because of an mmap deep >> in >> > its call stack, not because of "filesystem interactions" like I initially >> > thought. >> > >> >> What is the use case you need label listing from RT context for? >> >> Jan >> >> -- >> Siemens AG, T RDA IOT >> Corporate Competence Center Embedded Linux >> > > My use case is an IDDP-based pub/sub messaging system for real-time threads. > > Threads publish and subscribe to a channel ("xyz"). Any number of threads > can publish to any channel. And any number of threads can subscribe to any > channel (and each one should receive every message published to that > channel). > > Subscribers bind labeled IDDP sockets for each channel using labels like > so: <channel name>-<thread name>. If three threads subscribe to channel > "xyz" then I would expect /proc/xenomai/registry/rtipc/iddp to show: > xyz-threadA -> 0 > xyz-threadB -> 1 > xyz-threadC -> 2 > > For the pub/sub implementation to work, when thread X calls publish("xyz", > &message) the publish method would need to multicast the message to all > three of the IDDP sockets above. > This is pretty much what the Observable feature does in the EVL core which we are going to use for Xenomai 4: https://evlproject.org/core/user-api/observable/ Adding this feature natively to the existing RTIPC driver may be a better option than emulating it over IDDP. -- Philippe.
