That's a bad way of doing it in the first place. Instead:
if (getppid () == 1) my_parent_has_died ();
or:
ppid = getppid ();
if (getppid () != ppid) my_parent_has_died ();
Always remember, often it is more important to consider not what
applications "should" be doing, but rather what on the whole
applications and existing code "are" doing.
To demonstrate the importance of this. Do a sample of piece of UNIX
userlevel code which in some way uses parent destined signals for one
reason or another. Determine how many would be tripped up by a pid
allocation mechanism which recycled pids very fast. How quickly are
these source bases going to be "fixed" if we start using a PID
allocation which causes braindamaged situations for them?
I only have one gripe which my originally proposed scheme. Often I
like to be able to predict what PID a process will have for debugging
purposes. Fun stuff like catching network daemons spawned from inetd
dying on certain kinds of conditions, and I have 2 seconds or so to
attach. If you can predict pids very well, you can invoke the
incoming connection, and immediately sick strace or gdb on this daemon
in another window. Sure there are other ways to do this, especially
if I have the source but....
Later,
David S. Miller
davem@dm.cobaltmicro.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu