Re: question about mach ports and fork
On Jan 21, 2004, at 12:47 PM, Nathan T. Hjelm wrote: I know when fork/vfork are called that all mach ports are invalidated in the child process. Actually, only fork() and exec() invalidate the Mach ports. The current vfork() implementation actually arranges for the Mach task associated with the parent to be shared with the child (resulting in two procs running in one Mach task and having equal access to Mach resources like ports and VM). But it's only an implementation artifact and you shouldn't depend upon it. You must stick to the list of vfork()-safe APIs and behaviors (exec(), _exit(), not popping the stack, etc...) to assure continued operations regardless of the implementation. Is there any way to re-validate these ports and have them shared between the child and parent processes? I am particularly interested in being able to use IOServices assigned to the parent in the child process. There is no [guaranteed safe] way to re-validate them under the same port name with the same number of references (thus making the port names sprinkled throughout the process memory valid again). But there are some common techniques used to pass send rights to these ports from the parent to the child under a [randomly chosen] new name. And many of the frameworks allow for instantiation of objects passing an explicit port to use - rather than looking them anew. I'm not sure about IOService, however. You can't just open a new IOKit service connection in the child? This is sometimes impossible because the parent was privileged and the child not (so I feel your pain). Solving the problem in a general way at the Mach port level (by inheriting ports across fork()) would be nice, but it violates general assumptions like only one receive right being in existence for a given Mach port. Changing all the code that depends on these assumption is almost as difficult as working around the fork() problem in the first place. --Jim _______________________________________________ darwin-kernel mailing list | darwin-kernel@lists.apple.com Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/darwin-kernel Do not post admin requests to the list. They will be ignored.
participants (1)
-
Jim Magee