Philippe Gerum wrote:
On Sat, 2007-03-24 at 13:07 +0100, Viktor STARK wrote:
That looks like a pretty good solution. I'll be able to test this out on
Monday. I'll keep the list posted about my results.
Yeah, well, except that my last post was utter crap actually. I should
really consider having sleep because I don't even remember how my code
works, it seems. Ok, here is a fixed version: to sum up, you need to use
rt_queues to do what you want to do, i.e. exchanging data in primary
mode between real-time tasks. Performance-wise, there is no downside in
using queues instead of pipes anyway, except when rt_pipe_stream() is
actually appropriate for the sending side (i.e. when data is produced
incrementally by small chunks, and the reader has lower priority than
the sender).
I knew it was too good to be true. ;)
What I sketched would not work because rt_pipe_stream/read/write used
>from user-space would still feed the real-time endpoint of a pipe, which
could only be read from a non real-time endpoint.
Right. I guess feeding the same endpoint all the time won't really make
both sides communicate.
I knew that there was some reason why I hadn't even tried rt_pipe_* in
user space. Thanks for reminding me what that reason was. :)
IOW, there is no way
to use pipes for RT to RT communication, because data sent using
rt_pipe_write() is only readable by read(), and data wrote by write() is
only readable from rt_pipe_read(). The rt_pipe API is available from
user-space in order to feed regular Linux tasks with real-time data
produced from a user-space context, that's all.
Sorry for the noise. Yes Dmitry, I'm going to take a nap right now, in
order to fix this annoying -ENOBRAIN error that surges from time to
time. Gasp...
OK. So off I go with rt_queue_*. I'll keep the list posted.
Thanks again for all the support.
Viktor STARK
_______________________________________________
Xenomai-help mailing list
[email protected]
https://mail.gna.org/listinfo/xenomai-help
