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. > > 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
Description: OpenPGP digital signature
_______________________________________________ Xenomai-core mailing list Xenomaiemail@example.com https://mail.gna.org/listinfo/xenomai-core