Thanks. This is a pretty good lecture on OS's process. You are right. The problem is the Grandchild could not be trusted. And the child is stuck with the grandchild due to the way it launches The grandchild.
But since the parent knows child's pid, it could use this information To find out the grandchild's pid (as Packy proposed). I think that solves The problem pretty well. Ted Zeng Adobe Systems Inc. On 7/31/06 6:06 PM, "wren ng thornton" <[EMAIL PROTECTED]> wrote: > --- 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
