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

[Jan Kiszka <jan.kiszka@domain.hid>]

[-- 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 --]