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.

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

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

Reply via email to