hello. Isn't what you want to do very similar to what happens when a process goes into background and the parent dies? I.e. its parent gets reassigned to init, pid 1. That's a special case, but it seems like you could create a syscall that does that work and as long as the target parent is the same uid as the calling process, you should be able to re-use a lot of the code that does that inheritance for backrounded processes. Then, when the new parent does a wait, it just gets the pid of the newly transfered child, assuming the child exits at some point. Just a thought. -Brian
On Dec 8, 2:36pm, Mouse wrote: } Subject: Re: Reparenting processes? } > One complication I can think of: what happens to the original parent process$ } } If the original parent is not in a wait() at the time, I don't see this } as an issue; the child just evaporates. (See below.) } } If the original parent is in a wait(), and this is either its last } child or it is specifically being waited for (either by pid or pgid), } I'm not sure. I'd have to think about that. Possibly a new wait } status (WIFREPARENTED?). Possibly it just turns into whatever would } have happened if the wait*() had been done immediately after the } reparenting. Possibly something else. } } The new parent learning about the new child is not something I've been } worried about, because what I've been imagining requires active } collaboration between the old and new parents for the move to happen at } all, meaning that each parent is expecting the change and can update } whatever internal data structures it needs to. } } Yes, post-reparenting, the new parent can wait for the child just like } any other child it (then) has. } } /~\ The ASCII Mouse } \ / Ribbon Campaign } X Against HTML mo...@rodents-montreal.org } / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B >-- End of excerpt from Mouse