On Wed, Jun 17, 2009 at 12:30, Gilles Chanteperdrix<[email protected]> wrote: > Peter Soetens wrote: >> On Wed, Jun 17, 2009 at 10:09, Philippe Gerum<[email protected]> wrote: >>> As you have probably understood already, building a full real-time to >>> real-time data path using pipes is not possible; this said, this is not >>> the purpose of this API anyway, which has been designed for real-time to >>> non-RT communication. >> >> I was hoping to use rt_pipe + select in real-time context to implement >> a data receiving server for real-time inter-process communication. Is >> this possible ? >> What would happen if the real-time clients open the pipes as rt_pipes >> and start sending >> data in ? What's the alternative to listen in real-time to many >> connections from >> a single thread ? > > Note that posix message queues already work for inter-process > communications, with support for select. Depending on your needs, this > may be sufficient: you will need Xenomai threads on both sides, but the > non real-time one may use the SCHED_OTHER policy.
Thanks, I missed that. I thought that the mqd_t would not be compatible with file descriptors required by select. I think I can settle with Xenomai<->Xenomai only communication, since it's all running on the same host and our library initialises every thread as a Xenomai native task. It was a bit confusing which ipc primitive to use in which situation. We're still looking for the Holy grale (Any<->Any + select), but we're getting close :-) > > I was thinking, maybe we could map the xnpipe to a special flag in mq_open ? If POSIX compatibility is put up front, I don't think this will happen ? Peter _______________________________________________ Xenomai-help mailing list [email protected] https://mail.gna.org/listinfo/xenomai-help
