Re: [Xenomai-core] -EINTR using rt_pipe_read with TM_INFINITE

[Jan Kiszka <jan.kiszka@domain.hid>]

[-- Attachment #1: Type: text/plain, Size: 1644 bytes --]

Jacques GANGLOFF wrote:
> Hi,
> 
> I did this little test :
> 
> Below I have attached two sources, one on the kernel side and one on the
> user side.
> I do here a very simple fifo handshaking test. I insert the kernel module
> then I run the user program. When I do the test with the "THE BUG IS HERE"
> line commented, I got :
> 
> root@domain.hid# ./user
> user : j'ai envoyé A
> user :j'ai bien reçu E
> root@domain.hid# dmesg
> hello world
> kernel : j'ai bien reçu A
> kernel : ret = 1
> kernel :j'ai envoyé E
> 
> Now, when I uncomment the line :
> root@domain.hid# ./user
> user : j'ai envoyé A
> [CRTL-C] because the user program is blocking ...
> root@domain.hid# dmesg
> hello world
> kernel : j'ai bien reçu A
> kernel : ret = -4
> kernel :j'ai envoyé E
> 

That looks like a correct behaviour to me: the kernel module is trying
to read from pipe1 (MyPipe0, /dev/rtp0) and is blocked on it. The
user-space tool tries to do the same (is this intended BTW?). Then the
user-space program gets terminate, thus pipe1 is cleaned up. During that
cleanup all RT-readers on the pipe are woken up with -EINTR as return
code [1].

> 
> Now, ret=-4 is the code for -EINTR. According to the doc :
> "-EINTR is returned if rt_task_unblock() has been called for the waiting
> task before any data was available."
> 
> I cannot see where rt_task_unblock() could be called. What is wrong ?
> 

Ok, the documentation is insufficient here. We should actually add the
second reason for EINTR as sketched above.

Jan


[1]http://www.rts.uni-hannover.de/xenomai/lxr/source/ksrc/nucleus/pipe.c#L607


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 249 bytes --]