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.
_______________________________________________
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
