Re: [Xenomai-core] Auto closing of file descriptors and fork.
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 signature.asc Description: OpenPGP digital signature ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Auto closing of file descriptors and fork.
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. > > > > > 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 ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Auto closing of file descriptors and fork.
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 signature.asc Description: OpenPGP digital signature ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Auto closing of file descriptors and fork.
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
Re: [Xenomai-core] Auto closing of file descriptors and fork.
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 signature.asc Description: OpenPGP digital signature ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Auto closing of file descriptors and fork.
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. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Auto closing of file descriptors and fork.
On Dec 20, 2007 4:13 PM, Daniel Schnell <[EMAIL PROTECTED]> 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 ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Auto closing of file descriptors and fork.
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. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] Auto closing of file descriptors and fork.
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 ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
