--- quoth Packy Anderson: > --- quoth Ted Zeng: > > I don't know how the OS generate the pid for a > > process. That is why I don't > > feel comfortable with what I did. > > The way I understand it, the OS assigns the next > highest available pid when creating a process.
It' s never specifically documented because it's one of those "implementation dependent" things, but canonically speaking it's the "next available" pid which is either a first fit or next fit depending on which is easier to implement. Due to the nature of the lifecycles of processes this generally means that in practice child=ppid+1 but in actuality there is no guarantee that the two pids are related to one another. This general observation can be undone by wrapping of pids past the max pid, by some other process jumping in to spawn a child before your process' request is fulfilled, by other processes dying off and revealing a "better" next available pid, etc etc. Whenever a process makes a syscall to fork() an exact copy of the current process is made (including all open files and some other complexities), with the only difference being the pid. The other difference is that once the call to fork() returns the parent will receive the child's pid as a return value and the child will receive 0 (an invalid pid). If for for some reason the fork fails (e.g. no available pids), then the parent process will receive -1 (also an invalid pid). Generally it's up to the parent to keep track of their children and there's not much recourse to recovering them if you loose them. However the OS does keep track of such things (to deal with auto-reaping zombies and the like) and so there're often ways to recover that info. E.g. in C the waitpid() function has an option to wait for any child to die; I don't know of a Perl implementation if this call, but I wouldn't be surprised if it's out there, and if it isn't anyone with a bit of XS knowledge should be able to bang one out quickly. There may be other ways depending on the specific OS. I've only loosely been following this thread, but it sounds like the problem isn't the parent (the Perl script) keeping track of it's children, but rather keeping track of grandchildren. Since POSIX makes no province for keeping track of grandchildren, it's really something the child should keep track of and then report to the parent. That is, every process should clean up after themselves and so every parent can consider their child to be one process ignoring any other processes they may spin off. Of course it sounds like the child is an unknown (and not particularly trusted). Is there not any way for the Perl script to call the necessary grandchildren directly? Live well, ~wren __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
