Re: Reparenting processes?

[Brian Buhrow <buhrow%nfbcal.org@localhost>]

	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		mouse%rodents-montreal.org@localhost
} / \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B
>-- End of excerpt from Mouse