* Look up all IDDP/XDDP labels in the registry from userspace @ 2021-01-25 20:20 Sam Daniel 2021-01-25 21:07 ` Sam Daniel 0 siblings, 1 reply; 7+ messages in thread From: Sam Daniel @ 2021-01-25 20:20 UTC (permalink / raw) To: xenomai 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? ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Look up all IDDP/XDDP labels in the registry from userspace 2021-01-25 20:20 Look up all IDDP/XDDP labels in the registry from userspace Sam Daniel @ 2021-01-25 21:07 ` Sam Daniel 2021-01-26 18:07 ` Jan Kiszka 0 siblings, 1 reply; 7+ messages in thread From: Sam Daniel @ 2021-01-25 21:07 UTC (permalink / raw) To: xenomai On Mon, Jan 25, 2021 at 12:20 PM Sam Daniel <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. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Look up all IDDP/XDDP labels in the registry from userspace 2021-01-25 21:07 ` Sam Daniel @ 2021-01-26 18:07 ` Jan Kiszka 2021-01-26 19:44 ` Sam Daniel 0 siblings, 1 reply; 7+ messages in thread From: Jan Kiszka @ 2021-01-26 18:07 UTC (permalink / raw) To: Sam Daniel, xenomai 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> > 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Look up all IDDP/XDDP labels in the registry from userspace 2021-01-26 18:07 ` Jan Kiszka @ 2021-01-26 19:44 ` Sam Daniel 2021-01-26 20:00 ` Jan Kiszka 2021-01-27 6:24 ` Philippe Gerum 0 siblings, 2 replies; 7+ messages in thread From: Sam Daniel @ 2021-01-26 19:44 UTC (permalink / raw) To: Jan Kiszka; +Cc: xenomai On Tue, Jan 26, 2021 at 10:07 AM Jan Kiszka <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> > > 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. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Look up all IDDP/XDDP labels in the registry from userspace 2021-01-26 19:44 ` Sam Daniel @ 2021-01-26 20:00 ` Jan Kiszka 2021-01-26 20:37 ` Sebastian.Smolorz 2021-01-27 6:24 ` Philippe Gerum 1 sibling, 1 reply; 7+ messages in thread From: Jan Kiszka @ 2021-01-26 20:00 UTC (permalink / raw) To: Sam Daniel, Sebastian Smolorz; +Cc: xenomai 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. ;) Jan -- Siemens AG, T RDA IOT Corporate Competence Center Embedded Linux ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Look up all IDDP/XDDP labels in the registry from userspace 2021-01-26 20:00 ` Jan Kiszka @ 2021-01-26 20:37 ` Sebastian.Smolorz 0 siblings, 0 replies; 7+ messages in thread From: Sebastian.Smolorz @ 2021-01-26 20:37 UTC (permalink / raw) To: Jan Kiszka; +Cc: xenomai, Sam Daniel 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Look up all IDDP/XDDP labels in the registry from userspace 2021-01-26 19:44 ` Sam Daniel 2021-01-26 20:00 ` Jan Kiszka @ 2021-01-27 6:24 ` Philippe Gerum 1 sibling, 0 replies; 7+ messages in thread From: Philippe Gerum @ 2021-01-27 6:24 UTC (permalink / raw) To: Sam Daniel; +Cc: Jan Kiszka, xenomai Sam Daniel via Xenomai <xenomai@xenomai.org> writes: > On Tue, Jan 26, 2021 at 10:07 AM Jan Kiszka <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> >> > 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. ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2021-01-27 6:24 UTC | newest] Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2021-01-25 20:20 Look up all IDDP/XDDP labels in the registry from userspace Sam Daniel 2021-01-25 21:07 ` Sam Daniel 2021-01-26 18:07 ` Jan Kiszka 2021-01-26 19:44 ` Sam Daniel 2021-01-26 20:00 ` Jan Kiszka 2021-01-26 20:37 ` Sebastian.Smolorz 2021-01-27 6:24 ` Philippe Gerum
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.