Gilles Chanteperdrix wrote:
> On Dec 27, 2007 4:09 PM, Jan Kiszka <[EMAIL PROTECTED]> wrote:
>> Gilles Chanteperdrix wrote:
>>> On Dec 27, 2007 12:58 PM, Jan Kiszka <[EMAIL PROTECTED]> 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: signature.asc
Description: OpenPGP digital signature

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

Reply via email to