Date: Mon, 18 Jan 1999 02:48:57 -0800 From: Don Lewis <Don.Lewis@tsc.tdk.com> To: "Kent S. Harris" <ksh@vine.com>, freebsd-stable@FreeBSD.ORG Subject: Re: setpgid(2) doesn't work as advertised Message-ID: <199901181048.CAA05923@salsa.gv.tsc.tdk.com> In-Reply-To: "Kent S. Harris" <ksh@vine.com> "setpgid(2) doesn't work as advertised" (Jan 16, 11:56am)
next in thread | previous in thread | raw e-mail | index | archive | help
On Jan 16, 11:56am, "Kent S. Harris" wrote: } Subject: setpgid(2) doesn't work as advertised } I believe the manual is correct and the kernel code is wrong. Frequently } in industrial situations, an "area controller" process on a particular } CPU will spawn a number of sub-processes that perform various tasks } such as control special devices. One of the tasks of the "area } controller" is to reap its children and re-spawn them should they } unexpectedly abort. } } So far no problem. However, in a situation where the "area controller" } aborts and is restarted (usually manually), it may want to reclaim its } original children to the process group so it can once again reap } the SIGCHLD signals. To do so it must insert the children into } its new process group via setpgrp. No can do. When a process exits, the SIGCHLD is sent to its parent process, whether they are in the same process group or not. If the parent exits first, then its child processes are inherited by the init process (process 1). There is no way for another process to reclaim them. --- Truck To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199901181048.CAA05923>