Dmitry Adamushko wrote:
 > 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.

If we have a look at the sources, sys_read uses fput_light and
fget_light, which increment and decrement the file descriptor
reference count (member f_count of the file structure) used by fget and
fput when the file descriptor is shared between. open and close call
fget and fput.

"release" only get called through __fput when f_count reaches 0.

-- 


                                            Gilles Chanteperdrix.

Reply via email to