I'm working on a library (C++) that will be integrated into clients code. This lib will spawn a few child processes and must monitor them to respawn them as soon as they die (for any reason). I need to use vfork and exec to spawn those child processes.
I know I must use a signal handler to handle SIGCHLD and call waitpid to detect which child is dead. However, the user code may be using the same idea to handle its own child processes.
If I call waitpid, I'll retrieve information regarding any child process that may died (mine or not). If the dying process is mine, no problem... happy case. However, if it is from the user, he is not getting any information about that because I've already called waitpid.
How can I work around that?
My first idea is to use process groups. The first time I fork, I'd get the child pid and save it as a process group id. Each child that I'd create, I'd set it's group to this pid. Do you guys think that's a good choice? (I'm having trouble with that).
My second idea would be to reset the signal handler to the original one (or just call it). If I reraise the signal, the original handler would be able to get it. I'd have to reinstall my signal handler after that. Would it be a good choice?
My third choice would be using INFO (extended signal handler). I believe the pid of the dying process will be available in the info structure. If this is one of mine children, I'd call waitpid for that and that's ok. If that is not one of mine, I'd call the original signal handler. Would it be a good choice?
Just one last side question. To be able to call original signal handlers, should I always restore them and reraise the signal or just calling that as a function call is enough?
Thanks very much for your help.
Another option might be to spawn one child process first, which communicates with your main process through whatever IPC mechanism you like. Then, spawn the multiple child processes from within that new process, which gives you full control over the way the child processes terminate.