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.


---

Dmitry

_______________________________________________
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core

Reply via email to