Look up all IDDP/XDDP labels in the registry from userspace

Jan Kiszka jan.kiszka at siemens.com
Tue Jan 26 21:00:27 CET 2021

On 26.01.21 20:44, Sam Daniel wrote:
> On Tue, Jan 26, 2021 at 10:07 AM Jan Kiszka <jan.kiszka at siemens.com
> <mailto:jan.kiszka at siemens.com>> wrote:
>     On 25.01.21 22:07, Sam Daniel via Xenomai wrote:
>     > On Mon, Jan 25, 2021 at 12:20 PM Sam Daniel
>     <daniel.jacob.samuel at gmail.com <mailto:daniel.jacob.samuel at gmail.com>>
>     > 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.
> I would like to look up all labels in the registry from within the
> publish method to check if any subscribers have gone away or if any new
> subscribers have appeared and then adjust the multicast of the message
> accordingly.

RTIPC is not designed for such use cases - no multicast support as you
may have noticed already. Polling for labels to appear or disappear
would be a poor man's workaround. Still, you could make it "work": poll
with a non-RT thread for registry changes, update a lock-protected list
of subscribers, and use that list from the publish method in RT context.

That reminds of that simple (but rather domain specific) IPC driver we
once had, Sebastian. ;)


Siemens AG, T RDA IOT
Corporate Competence Center Embedded Linux

More information about the Xenomai mailing list