On Thursday 17 November 2005 20:17, you wrote:
> 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.
Exactly, I have just found out that and posted actually a long mail just
before getting this mail from you :o)
Yep, and before getting blocked, read() increments the counter as well, that's
why we don't have a xnpipe_realease() called as a result of close().
So everything is correct.
Xenomai-core mailing list