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

[Sebastian.Smolorz@gmx.de]

Hi Jan,

Jan Kiszka wrote:
> On 26.01.21 20:44, Sam Daniel wrote:
> > On Tue, Jan 26, 2021 at 10:07 AM Jan Kiszka <jan.kiszka@siemens.com
> > <mailto:jan.kiszka@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@gmail.com <mailto:daniel.jacob.samuel@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. ;)

Yeah, but that driver communicates over mailboxes rather than over
topics.

FWIW, it also is used in a really cool product. ;-)

— 
Sebastian