On Thursday 17 November 2005 18:24, Gilles Chanteperdrix wrote:
> Dmitry Adamushko wrote:
>  > > >As a conclusion, the behaviour that you observed with Xenomai
>  > > >pipes seems consistent with that of Linux' named pipes, except
>  > > >that in Linux read() returns 0, and not an error code as you
>  > > >observed with Xenomai.
>  > >
>  > > The read() call does *not* return when you close the *same* file
>  > > handle from another pthread in the same process.
>  >
>  > I confirm that and as I pointed it out in my previous mail - this is not
>  > how it's supposed to be.
>  > I'm currently on it. More news later.
> I am not sure about that: Linux regular pipes follow the same behaviour
> (the real destruction of the file descriptor is delayed until read()
> really returns).

My assertion was only based on the idea that nucleus::xnpipe_release() must be 
called as a result of any close() from the user space. And it, in turn, wakes 
up all the blocked readers. So the current implementation at least should 
have worked in sych a case. But, well, below is what I have observed.

Maybe your assertion may explain that.

The reason is actually not because of some problem in the xenomai codebase but 
because of the fact that nucleus::xnpipe_release() is _not_ called as I 
expected it to be :o)

The experiment was as follows (a slightly changed klatency test):

latency_module.ko uses a 10-second wait-interval for sending data

int fd; // pipe


// closing a pipe. Here I expected that nucleus::xnpipe_release() would be 
// called as a result (== file_operations::release ).

fd = open(/dev/rtpN);


read(fd, ...);  // blocked at least for 10 seconds so thread#2 closes a pipe 

if (error)


So xnpipe_release() is _not_ called as a result of the close() call in 
thread#2. close() returns 0 indeed.

10 seconds after its starting, thread#1 :: read() returns a valid block of 
data from the latency module and right after that - an error code is returned 
that the pipe is no longer valid.

I have taken a very brief look at the linux sources but it was not enough to 
get an explanation. So I'll take a closer look now :o)



Xenomai-core mailing list

Reply via email to