Peter Soetens wrote:
> 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 ?
The problem is that the only "POSIX way" I see to add a posix mapping
for the xnpipe API, is to add a non portable extension somewhere. It
could be a non portable message queues flag, or a non-portable socket
protocol. The problem with the socket protocol, is that we would open
one pipe end with the socket() call, and the other one with
open("/dev/rtpipe42"), which is a little bit cumbersome and why I
suggested to use socketpair instead, which would hide the call to open.
On the other hand, the same application does not necessarily need to
access the two sides of the pipe.
As for the holy grail you are looking for, message queues have
any<->any, but do not allow non real-time select. A mapping of xnpipe
would be asymetric, but would allow non real-time select on the non
real-time side, and real-time select on the real-time side.
By the way, I recently made a guide where I put some ideas on porting
POSIX applications to Xenomai, it mentions these issues:
http://www.xenomai.org/index.php/Porting_POSIX_applications_to_Xenomai
--
Gilles
_______________________________________________
Xenomai-help mailing list
[email protected]
https://mail.gna.org/listinfo/xenomai-help
