[Xenomai-core] Auto closing of file descriptors and fork.

[Xenomai-core] Auto closing of file descriptors and fork.

[Gilles Chanteperdrix]

Hi,

I have a problem with auto closing of file descriptors and fork. I
have an application (a modified pppd, to name it), which in a certain
mode (pppd "updetach" mode) opens some real-time file descriptors,
forks and exit the parent, continuing to use the file descriptors in
the child. The problem is that when exiting the parent, file
descriptors are automatically destroyed and therefore can not be used
in the child.

Any ideas for a fix ?

-- 
                                               Gilles Chanteperdrix

Re: [Xenomai-core] Auto closing of file descriptors and fork.

[Daniel Schnell]

Gilles Chanteperdrix wrote:
> Hi,
> 
> I have a problem with auto closing of file descriptors and fork. I
> have an application (a modified pppd, to name it), which in a certain
> mode (pppd "updetach" mode) opens some real-time file descriptors,
> forks and exit the parent, continuing to use the file descriptors in
> the child. The problem is that when exiting the parent, file
> descriptors are automatically destroyed and therefore can not be used
> in the child.      
> 
> Any ideas for a fix ?

Maybe not exiting the child but saying waitpid() ?



Daniel Schnell.

Re: [Xenomai-core] Auto closing of file descriptors and fork.

[Gilles Chanteperdrix]

On Dec 20, 2007 4:13 PM, Daniel Schnell <daniel.schnell@domain.hid> wrote:
> Gilles Chanteperdrix wrote:
> > Hi,
> >
> > I have a problem with auto closing of file descriptors and fork. I
> > have an application (a modified pppd, to name it), which in a certain
> > mode (pppd "updetach" mode) opens some real-time file descriptors,
> > forks and exit the parent, continuing to use the file descriptors in
> > the child. The problem is that when exiting the parent, file
> > descriptors are automatically destroyed and therefore can not be used
> > in the child.
> >
> > Any ideas for a fix ?
>
> Maybe not exiting the child but saying waitpid() ?

The problem is that the aim of pppd updetach is to exit the parent
once the connection is established, so that the script running pppd
can continue.

-- 
                                               Gilles Chanteperdrix

Re: [Xenomai-core] Auto closing of file descriptors and fork.

[Gilles Chanteperdrix]

Gilles Chanteperdrix wrote:
 > Hi,
 > 
 > I have a problem with auto closing of file descriptors and fork. I
 > have an application (a modified pppd, to name it), which in a certain
 > mode (pppd "updetach" mode) opens some real-time file descriptors,
 > forks and exit the parent, continuing to use the file descriptors in
 > the child. The problem is that when exiting the parent, file
 > descriptors are automatically destroyed and therefore can not be used
 > in the child.
 > 
 > Any ideas for a fix ?

More precisely. We need to trap the "fork" event, and handle it in the
skins event callbacks. We will need to create a new ppd structure for
the new process, but what will we do with the skin objects ? If we keep
the same objects for the child and increment a reference count, we will
end up with an object that need to be inserted in two per-process
lists. If we create new objects, how will we manage for user-space
references (inherited accross fork) to remain valid ?

-- 


					    Gilles Chanteperdrix.

Re: [Xenomai-core] Auto closing of file descriptors and fork.

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 1539 bytes --]

Gilles Chanteperdrix wrote:
> Gilles Chanteperdrix wrote:
>  > Hi,
>  > 
>  > I have a problem with auto closing of file descriptors and fork. I
>  > have an application (a modified pppd, to name it), which in a certain
>  > mode (pppd "updetach" mode) opens some real-time file descriptors,
>  > forks and exit the parent, continuing to use the file descriptors in
>  > the child. The problem is that when exiting the parent, file
>  > descriptors are automatically destroyed and therefore can not be used
>  > in the child.
>  > 
>  > Any ideas for a fix ?
> 
> More precisely. We need to trap the "fork" event, and handle it in the
> skins event callbacks. We will need to create a new ppd structure for
> the new process, but what will we do with the skin objects ? If we keep
> the same objects for the child and increment a reference count, we will
> end up with an object that need to be inserted in two per-process
> lists. If we create new objects, how will we manage for user-space
> references (inherited accross fork) to remain valid ?

The only way I see are process-private file descriptor tables +
reference counters for the underlying objects. On fork, the descriptor
table would be cloned and the reference counter of the contained object
would be incremented, creating another reference to them. Or should we
rather re-open those objects, creating another instance?

BTW, by adding a fork hook, my old idea of storing the ppd reference in
some I-pipe ptdkey comes into reach again.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 254 bytes --]

Re: [Xenomai-core] Auto closing of file descriptors and fork.

[Gilles Chanteperdrix]

On Dec 27, 2007 12:58 PM, Jan Kiszka <jan.kiszka@domain.hid> wrote:
>
> Gilles Chanteperdrix wrote:
> > Gilles Chanteperdrix wrote:
> >  > Hi,
> >  >
> >  > I have a problem with auto closing of file descriptors and fork. I
> >  > have an application (a modified pppd, to name it), which in a certain
> >  > mode (pppd "updetach" mode) opens some real-time file descriptors,
> >  > forks and exit the parent, continuing to use the file descriptors in
> >  > the child. The problem is that when exiting the parent, file
> >  > descriptors are automatically destroyed and therefore can not be used
> >  > in the child.
> >  >
> >  > Any ideas for a fix ?
> >
> > More precisely. We need to trap the "fork" event, and handle it in the
> > skins event callbacks. We will need to create a new ppd structure for
> > the new process, but what will we do with the skin objects ? If we keep
> > the same objects for the child and increment a reference count, we will
> > end up with an object that need to be inserted in two per-process
> > lists. If we create new objects, how will we manage for user-space
> > references (inherited accross fork) to remain valid ?
>
> The only way I see are process-private file descriptor tables +
> reference counters for the underlying objects. On fork, the descriptor
> table would be cloned and the reference counter of the contained object
> would be incremented, creating another reference to them. Or should we
> rather re-open those objects, creating another instance?

That is essentially the two alternatives I propose.

The problem when cloning the file descriptor table is that if there is
an xnholder_t (or something similar) in a file descriptor object, the
file descriptor can only be linked to one table.

The problem of re-opening the objects is that the user-space
references to the re-opened object should be updated. It is impossible
for a file descriptor.

-- 
                                               Gilles Chanteperdrix

Re: [Xenomai-core] Auto closing of file descriptors and fork.

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 2385 bytes --]

Gilles Chanteperdrix wrote:
> On Dec 27, 2007 12:58 PM, Jan Kiszka <jan.kiszka@domain.hid> wrote:
>> Gilles Chanteperdrix wrote:
>>> Gilles Chanteperdrix wrote:
>>>  > Hi,
>>>  >
>>>  > I have a problem with auto closing of file descriptors and fork. I
>>>  > have an application (a modified pppd, to name it), which in a certain
>>>  > mode (pppd "updetach" mode) opens some real-time file descriptors,
>>>  > forks and exit the parent, continuing to use the file descriptors in
>>>  > the child. The problem is that when exiting the parent, file
>>>  > descriptors are automatically destroyed and therefore can not be used
>>>  > in the child.
>>>  >
>>>  > Any ideas for a fix ?
>>>
>>> More precisely. We need to trap the "fork" event, and handle it in the
>>> skins event callbacks. We will need to create a new ppd structure for
>>> the new process, but what will we do with the skin objects ? If we keep
>>> the same objects for the child and increment a reference count, we will
>>> end up with an object that need to be inserted in two per-process
>>> lists. If we create new objects, how will we manage for user-space
>>> references (inherited accross fork) to remain valid ?
>> The only way I see are process-private file descriptor tables +
>> reference counters for the underlying objects. On fork, the descriptor
>> table would be cloned and the reference counter of the contained object
>> would be incremented, creating another reference to them. Or should we
>> rather re-open those objects, creating another instance?
> 
> That is essentially the two alternatives I propose.
> 
> The problem when cloning the file descriptor table is that if there is
> an xnholder_t (or something similar) in a file descriptor object, the
> file descriptor can only be linked to one table.

Hmm, where is there difference between this cloning and "normal"
multi-threaded usage? The only difference I see is that there are now
two separated address spaces from the user perspective. But for the
kernel, it stays the same.

> 
> The problem of re-opening the objects is that the user-space
> references to the re-opened object should be updated. It is impossible
> for a file descriptor.

The only user space reference is the file descriptor - an index. And as
this index stays the same across the fork, I don't see the problem.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 254 bytes --]

Re: [Xenomai-core] Auto closing of file descriptors and fork.

[Gilles Chanteperdrix]

On Dec 27, 2007 4:09 PM, Jan Kiszka <jan.kiszka@domain.hid> wrote:
>
> Gilles Chanteperdrix wrote:
> > On Dec 27, 2007 12:58 PM, Jan Kiszka <jan.kiszka@domain.hid> wrote:
> >> Gilles Chanteperdrix wrote:
> >>> Gilles Chanteperdrix wrote:
> >>>  > Hi,
> >>>  >
> >>>  > I have a problem with auto closing of file descriptors and fork. I
> >>>  > have an application (a modified pppd, to name it), which in a certain
> >>>  > mode (pppd "updetach" mode) opens some real-time file descriptors,
> >>>  > forks and exit the parent, continuing to use the file descriptors in
> >>>  > the child. The problem is that when exiting the parent, file
> >>>  > descriptors are automatically destroyed and therefore can not be used
> >>>  > in the child.
> >>>  >
> >>>  > Any ideas for a fix ?
> >>>
> >>> More precisely. We need to trap the "fork" event, and handle it in the
> >>> skins event callbacks. We will need to create a new ppd structure for
> >>> the new process, but what will we do with the skin objects ? If we keep
> >>> the same objects for the child and increment a reference count, we will
> >>> end up with an object that need to be inserted in two per-process
> >>> lists. If we create new objects, how will we manage for user-space
> >>> references (inherited accross fork) to remain valid ?
> >> The only way I see are process-private file descriptor tables +
> >> reference counters for the underlying objects. On fork, the descriptor
> >> table would be cloned and the reference counter of the contained object
> >> would be incremented, creating another reference to them. Or should we
> >> rather re-open those objects, creating another instance?
> >
> > That is essentially the two alternatives I propose.
> >
> > The problem when cloning the file descriptor table is that if there is
> > an xnholder_t (or something similar) in a file descriptor object, the
> > file descriptor can only be linked to one table.
>
> Hmm, where is there difference between this cloning and "normal"
> multi-threaded usage? The only difference I see is that there are now
> two separated address spaces from the user perspective. But for the
> kernel, it stays the same.

If there are two ppds, there are two lists (or hash table, or whatever
data structure). So, we now have an object, with only one xnholder_t
(or list_head) that must be in two lists. This does not work.

>
> >
> > The problem of re-opening the objects is that the user-space
> > references to the re-opened object should be updated. It is impossible
> > for a file descriptor.
>
> The only user space reference is the file descriptor - an index. And as
> this index stays the same across the fork, I don't see the problem.

The user-space file descriptor is __rtdm_fd_start + kernel-space file
descriptor. If you re-open an object, you will obtain a new
kernel-space file descriptor, and hence a different user-space file
descriptor. So, no, the index will not stay the same across the fork.

-- 
                                               Gilles Chanteperdrix

Re: [Xenomai-core] Auto closing of file descriptors and fork.

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 3662 bytes --]

Gilles Chanteperdrix wrote:
> On Dec 27, 2007 4:09 PM, Jan Kiszka <jan.kiszka@domain.hid> wrote:
>> Gilles Chanteperdrix wrote:
>>> On Dec 27, 2007 12:58 PM, Jan Kiszka <jan.kiszka@domain.hid> wrote:
>>>> Gilles Chanteperdrix wrote:
>>>>> Gilles Chanteperdrix wrote:
>>>>>  > Hi,
>>>>>  >
>>>>>  > I have a problem with auto closing of file descriptors and fork. I
>>>>>  > have an application (a modified pppd, to name it), which in a certain
>>>>>  > mode (pppd "updetach" mode) opens some real-time file descriptors,
>>>>>  > forks and exit the parent, continuing to use the file descriptors in
>>>>>  > the child. The problem is that when exiting the parent, file
>>>>>  > descriptors are automatically destroyed and therefore can not be used
>>>>>  > in the child.
>>>>>  >
>>>>>  > Any ideas for a fix ?
>>>>>
>>>>> More precisely. We need to trap the "fork" event, and handle it in the
>>>>> skins event callbacks. We will need to create a new ppd structure for
>>>>> the new process, but what will we do with the skin objects ? If we keep
>>>>> the same objects for the child and increment a reference count, we will
>>>>> end up with an object that need to be inserted in two per-process
>>>>> lists. If we create new objects, how will we manage for user-space
>>>>> references (inherited accross fork) to remain valid ?
>>>> The only way I see are process-private file descriptor tables +
>>>> reference counters for the underlying objects. On fork, the descriptor
>>>> table would be cloned and the reference counter of the contained object
>>>> would be incremented, creating another reference to them. Or should we
>>>> rather re-open those objects, creating another instance?
>>> That is essentially the two alternatives I propose.
>>>
>>> The problem when cloning the file descriptor table is that if there is
>>> an xnholder_t (or something similar) in a file descriptor object, the
>>> file descriptor can only be linked to one table.
>> Hmm, where is there difference between this cloning and "normal"
>> multi-threaded usage? The only difference I see is that there are now
>> two separated address spaces from the user perspective. But for the
>> kernel, it stays the same.
> 
> If there are two ppds, there are two lists (or hash table, or whatever
> data structure). So, we now have an object, with only one xnholder_t
> (or list_head) that must be in two lists. This does not work.

At least for RTDM, objects that are addressed via file descriptors are
not managed in ppd tables. Instead, the descriptor table already
contains enough information to find those objects on process
termination. At the moment, there is an owner field in the object
required to tell the ownerships apart. With process-private descriptor
tables this field would become obsolete.

> 
>>> The problem of re-opening the objects is that the user-space
>>> references to the re-opened object should be updated. It is impossible
>>> for a file descriptor.
>> The only user space reference is the file descriptor - an index. And as
>> this index stays the same across the fork, I don't see the problem.
> 
> The user-space file descriptor is __rtdm_fd_start + kernel-space file
> descriptor. If you re-open an object, you will obtain a new
> kernel-space file descriptor, and hence a different user-space file
> descriptor. So, no, the index will not stay the same across the fork.

Not with the current implementation, true. But as I said: the
prerequisite for fork-persistent file descriptors are process-private
descriptor tables anyway. And at that point, the indexes will stay the same.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 254 bytes --]