Mario DeFazio wrote: > It's been too long since I've done down and dirty programming, > so I'm a bit rusty, but I have just encountered an situation that > puzzles me. > > I want to watch for the termination of a process that isn't my direct > child, > and I'd prefer and event-based method. > I now realize waitpid(2) can't do this because it just doesn't inform > the parent of a child process termination, it frees up the child's > resources.
But at that point the child is dead, so it no longer need resources! > So I'd really need something like a watchpid() function that does only > the notification > half of a waitpid(). waitpid is limited to parent-child relationships. > Is there a standard event-based method for watching for a > non-direct-child process termination? > I have used polling methods (checking existence of /proc/$pid is my > favorite) > but that's expensive by comparison especially if you need high > resolution timing. Using "kill -0 $pid" is more portable, and probably much less resource hungry, than testing for existence of /proc/$pid. It just sends the signal, rather than needing to populate the /proc virtual directory. Ignoring for the moment the question "why", if you *need* high resolution then probably your best bet is using the ptrace system call if it has been extended to allow you to attach to already running processes. Most systems have this extension. However the "why" is an important question! Can you rethink your requirement to perhaps wrap your program (identified by $pid above) with a program that watches (using wait/waitpid) for it to terminate and then using some form of interprocess communication (e.g. signal, write...) to say it has gone? _______________________________________________ ast-users mailing list [email protected] https://mailman.research.att.com/mailman/listinfo/ast-users
