Messages in this thread | | | Date | Tue, 24 Feb 1998 19:35:13 -0800 | From | "David S. Miller" <> | Subject | Re: PID sequences |
| |
Date: Wed, 25 Feb 1998 14:26:33 +1100 From: Richard Gooch <rgooch@atnf.CSIRO.AU>
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
| |