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 <[email protected] > > <mailto:[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] <mailto:[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. > > > > 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
