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.