[Xenomai] Unable to Read from Pipe

[Xenomai] Unable to Read from Pipe

[C Smith]

I am developing a set of applications which write to and read from a
rt_pipe. The writing app is in plain linux userspace, the reading app is a
periodic Xenomai task. I am using xenomai 2.6.3 on kernel 3.4.6 (32 bit).

The problem I have is that the Xenomai task gets this warning when it tries
to read the pipe:
"errno 11 -EWOULDBLOCK" and the bytes the userspace app sent never arrive
at the Xenomai task.

The Xenomai task creates the pipe this way:

ret = rt_pipe_create(&cmd_fifo_fd, "cmd_fifo", 0, 30);

The userspace app opens and writes to the pipe this way:

fd = open("/dev/rtp0", O_RDWR);
wr = write(fd, "Debug", sizeof("Debug"));

The Xenomai task becomes periodic like this:

 ret = rt_task_create(&main_task, "mytask", 0, 99, T_FPU | T_JOINABLE);
 ret = rt_task_start(&main_task, &Periodic_routine, NULL);

Each time the Xenomai periodic task 'wakes', it checks the pipe in a
non-blocking fashion (this is a requirement).
Here is most of the periodic code which reads the pipe:

void Periodic_routine(void *cookie) {
   RTIME next;
   rt_task_set_mode(0, T_WARNSW, NULL);
   next = rt_timer_read();
   while (1)   {
      next += 2000000000;
      retval = rt_task_sleep_until(next);
      retval = rt_pipe_read(&cmd_fifo_fd, msg, 6, TM_NONBLOCK);
   }
}

Yet the rt_pipe_read() above always returns errno 11 -EWOULDBLOCK and never
gets any bytes from the pipe, no matter how many times the periodic task
wakes up.

-CSmith

Re: [Xenomai] Unable to Read from Pipe

[Gilles Chanteperdrix]

On Mon, Jun 29, 2015 at 04:57:47PM -0700, C Smith wrote:
> I am developing a set of applications which write to and read from a
> rt_pipe. The writing app is in plain linux userspace, the reading app is a
> periodic Xenomai task. I am using xenomai 2.6.3 on kernel 3.4.6 (32 bit).

Do you have the same problem with xenomai latest stable version? If
yes, do you have it with xenomai testing version?
Do you have the same problem with xddp sockets ?


-- 
					    Gilles.
https://click-hack.org

Re: [Xenomai] Unable to Read from Pipe

[Gilles Chanteperdrix]

On Wed, Jul 01, 2015 at 10:44:53AM -0700, C Smith wrote:
> I tried xenomai stable 2.6.4 on a 3.14.17 kernel today. I get the same
> result,

What about the other tests? Xenomai testing? and XDDP sockets?

> the rt task pipe read results in errno 11 -EWOULDBLOCK.  Here is a clue:
> a blocking read in the periodic task works OK and reads the bytes from the
> pipe - but I can't allow my periodic thread to block.
> 
> The nonblocking pipe API should work in xenomai 2.6.4, right? Perhaps there
> is something I'm doing wrong in my code or my compile?
> I have attached my test code for you to look at, in case I am doing
> something wrong.

There is no doubt that it should be working. But maybe it does not,
and understanding why would be a waste of time if it has been fixed
in Xenomai testing.

Please stay on the lit.
-- 
					    Gilles.
https://click-hack.org

Re: [Xenomai] Unable to Read from Pipe

[C Smith]

I have installed Xenomai 3.0rc5 and compiled my test applications (with
minor revisions for the new API).
I modprobed the xeno_rtipc module for this, and my apps run.  But I am
getting the exact same error in the periodic task which attempts a
nonblocking read of a pipe: errno 11 -EWOULDBLOCK, and no bytes are ever
transferred across the pipe.

It seems unlikely that the Pipe API has been broken across Xenomai 2.6.2,
2.6.4 and 3.0rc5.
So perhaps there is something wrong with my code or the way I compile the
apps?

The gcc command line for the periodic task is this:
gcc -I/usr/xenomai/include/cobalt -I/usr/xenomai/include -D_GNU_SOURCE
-D_REENTRANT -D__COBALT__ -I/usr/xenomai/include/alchemy     -Xlinker
-rpath -Xlinker /usr/xenomai/lib  pipe-read.c
-Wl,@/usr/xenomai/lib/cobalt.wrappers
/usr/xenomai/lib/xenomai/bootstrap.o -Wl,--wrap=main
-Wl,--dynamic-list=/usr/xenomai/lib/dynlist.ld -L/usr/xenomai/lib -lcobalt
-lpthread -lrt     -lalchemy -lcopperplate -Wl,--wrap=main
-Wl,--dynamic-list=/usr/xenomai/lib/dynlist.ld -L/usr/xenomai/lib -lcobalt
-lpthread -lrt    -o pipe-read

I have attached the latest 'write' and 'read' test apps here.

Please help. Thanks,
-C Smith

On Wed, Jul 1, 2015 at 10:54 AM, Gilles Chanteperdrix <
gilles.chanteperdrix@xenomai.org> wrote:

> On Wed, Jul 01, 2015 at 10:44:53AM -0700, C Smith wrote:
> > I tried xenomai stable 2.6.4 on a 3.14.17 kernel today. I get the same
> > result,
>
> What about the other tests? Xenomai testing? and XDDP sockets?
>
> > the rt task pipe read results in errno 11 -EWOULDBLOCK.  Here is a clue:
> > a blocking read in the periodic task works OK and reads the bytes from
> the
> > pipe - but I can't allow my periodic thread to block.
> >
> > The nonblocking pipe API should work in xenomai 2.6.4, right? Perhaps
> there
> > is something I'm doing wrong in my code or my compile?
> > I have attached my test code for you to look at, in case I am doing
> > something wrong.
>
> There is no doubt that it should be working. But maybe it does not,
> and understanding why would be a waste of time if it has been fixed
> in Xenomai testing.
>
> Please stay on the lit.
> --
>                                             Gilles.
> https://click-hack.org
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pipe-write.c
Type: text/x-csrc
Size: 395 bytes
Desc: not available
URL: <http://xenomai.org/pipermail/xenomai/attachments/20150702/60eda063/attachment.c>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pipe-read.c
Type: text/x-csrc
Size: 3254 bytes
Desc: not available
URL: <http://xenomai.org/pipermail/xenomai/attachments/20150702/60eda063/attachment-0001.c>

Re: [Xenomai] Unable to Read from Pipe

[C Smith]

I found a workaround for this, but I believe it illustrates a bug in
xenomai 3.0rc5, which is also present in in xenomai 2.6.4.

The problem is that if the userspace writer of a pipe closes the pipe
immediately after writing, the data does not get into the pipe reliably and
the real-time reader process usually doesn't get the data. This is true
even though the write() returns the expected number of bytes indicating
success.

The workaround is to add a usleep in the writer process and wait until the
data "gets into" the pipe before closing the pipe. The critical time period
in my tests seems to be about .5 seconds, if less than that there is often
data loss.

Here is my new userspace pipe-write.c :

     fd = open("/dev/rtp0", O_WRONLY);
    printf("open returned file descriptor: %d\n", fd);

    wr = write(fd, "Debug", sizeof("Debug"));
    printf("Write call retuned: %d\n", wr);

    usleep(500000);   //This sleep makes the write reliable
//    usleep(125000);   //This one is very unreliable

    if (fd > 0)
       close(fd);

This code succeeds but the usleep() is just an open-loop guess as to how
long to wait before close().

Is there any way to verify that bytes have been written to the rt_pipe ?
(Perhaps by checking /proc/xenomai?)

On Thu, Jul 2, 2015 at 4:14 PM, C Smith <csmithquestions@gmail.com> wrote:

> I have installed Xenomai 3.0rc5 and compiled my test applications (with
> minor revisions for the new API).
> I modprobed the xeno_rtipc module for this, and my apps run.  But I am
> getting the exact same error in the periodic task which attempts a
> nonblocking read of a pipe: errno 11 -EWOULDBLOCK, and no bytes are ever
> transferred across the pipe.
>
> It seems unlikely that the Pipe API has been broken across Xenomai 2.6.2,
> 2.6.4 and 3.0rc5.
> So perhaps there is something wrong with my code or the way I compile the
> apps?
>
> The gcc command line for the periodic task is this:
> gcc -I/usr/xenomai/include/cobalt -I/usr/xenomai/include -D_GNU_SOURCE
> -D_REENTRANT -D__COBALT__ -I/usr/xenomai/include/alchemy     -Xlinker
> -rpath -Xlinker /usr/xenomai/lib  pipe-read.c
> -Wl,@/usr/xenomai/lib/cobalt.wrappers
> /usr/xenomai/lib/xenomai/bootstrap.o -Wl,--wrap=main
> -Wl,--dynamic-list=/usr/xenomai/lib/dynlist.ld -L/usr/xenomai/lib -lcobalt
> -lpthread -lrt     -lalchemy -lcopperplate -Wl,--wrap=main
> -Wl,--dynamic-list=/usr/xenomai/lib/dynlist.ld -L/usr/xenomai/lib -lcobalt
> -lpthread -lrt    -o pipe-read
>
> I have attached the latest 'write' and 'read' test apps here.
>
> Please help. Thanks,
> -C Smith
>
> On Wed, Jul 1, 2015 at 10:54 AM, Gilles Chanteperdrix <
> gilles.chanteperdrix@xenomai.org> wrote:
>
>> On Wed, Jul 01, 2015 at 10:44:53AM -0700, C Smith wrote:
>> > I tried xenomai stable 2.6.4 on a 3.14.17 kernel today. I get the same
>> > result,
>>
>> What about the other tests? Xenomai testing? and XDDP sockets?
>>
>> > the rt task pipe read results in errno 11 -EWOULDBLOCK.  Here is a clue:
>> > a blocking read in the periodic task works OK and reads the bytes from
>> the
>> > pipe - but I can't allow my periodic thread to block.
>> >
>> > The nonblocking pipe API should work in xenomai 2.6.4, right? Perhaps
>> there
>> > is something I'm doing wrong in my code or my compile?
>> > I have attached my test code for you to look at, in case I am doing
>> > something wrong.
>>
>> There is no doubt that it should be working. But maybe it does not,
>> and understanding why would be a waste of time if it has been fixed
>> in Xenomai testing.
>>
>> Please stay on the lit.
>> --
>>                                             Gilles.
>> https://click-hack.org
>>
>
>

Re: [Xenomai] Unable to Read from Pipe

[Philippe Gerum]

On 07/20/2015 11:31 PM, C Smith wrote:
> I found a workaround for this, but I believe it illustrates a bug in
> xenomai 3.0rc5, which is also present in in xenomai 2.6.4.
> 
> The problem is that if the userspace writer of a pipe closes the pipe
> immediately after writing, the data does not get into the pipe reliably and
> the real-time reader process usually doesn't get the data. This is true
> even though the write() returns the expected number of bytes indicating
> success.
> 

This is intended. We must allow the regular side to force a shutdown on
the pipe since this is a valid use case, which would not be possible if
waiting for the rt input to drain was the only option before the kernel
actually closes the channel.

O_SYNC can be passed to open() to have the writer wait for the rt side
to start consuming the messages on the other end. In addition, we could
make the close() call wait until the rt input is fully consumed with
O_SYNC too, which is not the case so far (we currently sync on write()
only). This patch has been scrupulously untested.

diff --git a/ksrc/nucleus/pipe.c b/ksrc/nucleus/pipe.c
index df587ab..5367c4c 100644
--- a/ksrc/nucleus/pipe.c
+++ b/ksrc/nucleus/pipe.c
@@ -697,6 +697,14 @@ static int xnpipe_release(struct inode *inode,
struct file *file)

 	xnlock_get_irqsave(&nklock, s);

+	if ((file->f_flags & O_SYNC) != 0 && !emptyq_p(&state->inq)) {
+		if (xnpipe_wait(state, XNPIPE_USER_WSYNC, s,
+				emptyq_p(&state->inq))) {
+			xnlock_put_irqrestore(&nklock, s);
+			return -ERESTARTSYS;
+		}
+	}
+
 	xnpipe_dequeue_all(state, XNPIPE_USER_WREAD);
 	xnpipe_dequeue_all(state, XNPIPE_USER_WSYNC);

-- 
Philippe.

Re: [Xenomai] Unable to Read from Pipe

[C Smith]

That code snippet explains it well, and my tests confirm the principle. I
no longer lose bytes when I open() with O_SYNC flag, write(),  and close()
shortly thereafter.I don't think you need to "make the close() call wait
until the rt input is fully consumed".

This man page is clear on the expected behavior and benefits of O_SYNC:
http://man7.org/linux/man-pages/man2/open.2.html

Thanks, Philippe.

On Tue, Jul 21, 2015 at 1:26 AM, Philippe Gerum <rpm@xenomai.org> wrote:

> On 07/20/2015 11:31 PM, C Smith wrote:
> > I found a workaround for this, but I believe it illustrates a bug in
> > xenomai 3.0rc5, which is also present in in xenomai 2.6.4.
> >
> > The problem is that if the userspace writer of a pipe closes the pipe
> > immediately after writing, the data does not get into the pipe reliably
> and
> > the real-time reader process usually doesn't get the data. This is true
> > even though the write() returns the expected number of bytes indicating
> > success.
> >
>
> This is intended. We must allow the regular side to force a shutdown on
> the pipe since this is a valid use case, which would not be possible if
> waiting for the rt input to drain was the only option before the kernel
> actually closes the channel.
>
> O_SYNC can be passed to open() to have the writer wait for the rt side
> to start consuming the messages on the other end. In addition, we could
> make the close() call wait until the rt input is fully consumed with
> O_SYNC too, which is not the case so far (we currently sync on write()
> only). This patch has been scrupulously untested.
>
> diff --git a/ksrc/nucleus/pipe.c b/ksrc/nucleus/pipe.c
> index df587ab..5367c4c 100644
> --- a/ksrc/nucleus/pipe.c
> +++ b/ksrc/nucleus/pipe.c
> @@ -697,6 +697,14 @@ static int xnpipe_release(struct inode *inode,
> struct file *file)
>
>         xnlock_get_irqsave(&nklock, s);
>
> +       if ((file->f_flags & O_SYNC) != 0 && !emptyq_p(&state->inq)) {
> +               if (xnpipe_wait(state, XNPIPE_USER_WSYNC, s,
> +                               emptyq_p(&state->inq))) {
> +                       xnlock_put_irqrestore(&nklock, s);
> +                       return -ERESTARTSYS;
> +               }
> +       }
> +
>         xnpipe_dequeue_all(state, XNPIPE_USER_WREAD);
>         xnpipe_dequeue_all(state, XNPIPE_USER_WSYNC);
>
> --
> Philippe.
>