Thanks -- I'm all for using the most-well-traveled path -- do you mean the message queue API?
Bob P.S. I'll be on vacation for a week On Wed, Aug 16, 2017 at 6:19 AM, Philippe Gerum <r...@xenomai.org> wrote: > On 08/16/2017 02:14 AM, C Smith wrote: > > Oops, I accidentally sent this to Philippe instead of the list -- > > > > ---------- Forwarded message ---------- > > From: C Smith <csmithquesti...@gmail.com> > > Date: Mon, Aug 14, 2017 at 3:48 PM > > Subject: Re: [Xenomai] rt_pipe_* - must link xenomai and flush the pipe > > To: Philippe Gerum <r...@xenomai.org> > > > > > > Thanks -- sorry I was sparse with details -- > > - what are the parameters passed to rt_pipe_create(), rt_pipe_read() in > the failing case? (sizes, flags etc). > > - what is the exact return value of write() on the non-rt side, which > does not trigger any receipt from rt_pipe_read()? > > - what is the _exact_ Xenomai 2.6 release you have been using so far? > Several bug fixes have been applied to the message pipes along the 2.6.x > lifetime, only 2.6.5 includes them all. > > > > > I am using xenomai 2.6. > > I would strongly recommend to use Xenomai 3.0.x instead of 2.6. The > Xenomai 2.6.x series is not maintained anymore (EOL since January last > year). > > I would also recommend to go for the POSIX interface instead of the > so-called native/alchemy API: less overhead, more users, better > maintenance. With Xenomai 3.x, the POSIX API is truly the "native" one, > compared to all other APIs - include alchemy - which have to go through > the "Copperplate" mediation layer for reaching the core real-time services. > > Xenomai's "alchemy" API should be seen as a compatibility layer for > people who want to port Xenomai 2.6 applications originally implemented > with the "native" API to Xenomai 3.x. I would NOT recommend it for new > projects. > > I am observing this behavior when a non-RT task > > writes to the pipe using write(), and an RT task reads the pipe with > > rt_pipe_read. The RT task is not a kernel module, just started from an > ELF > > executable I run from the command line. > > > > BTW, linking in xenomai libraries makes a huge difference -- according to > > gdb, when I leave xenomai libraries out (of a program with no xenomai > calls > > and no threading calls), the process is single-threaded; but when I link > it > > with -lxenomai -lpthread_rt then gdb shows two threads, even if I stop it > > immediately by typing 'break main' before 'run'. One of the threads > always > > has this call stack: > > > > #0 0xffffe424 in __kernel_vsyscall () > > #1 0xb7e90966 in nanosleep () from /lib/libpthread.so.0 > > #2 0xb7ea0819 in printer_loop (arg=0x0) at rt_print.c:691 > > #3 0xb7e89adf in start_thread () from /lib/libpthread.so.0 > > #4 0xb720d55e in clone () from /lib/libc.so.6 > > > > That is expected; this is a helper thread started from a Xenomai library > constructor, dealing with deferred printf() output. > > -- > Philippe. > _______________________________________________ Xenomai mailing list Xenomai@xenomai.org https://xenomai.org/mailman/listinfo/xenomai
