Just some memories about UNIX child processes here - On UNIX systems where I have a daemon fork children, often I build into its service loop a nonblocking wait for any suspended children. (NOHANG). I agree it's good to get the return status of the children. - As a last resort, I suppose one could ioctl the file in the proc directory for a process. - Using SIGCHLD can be tricky if some children are forked by third party code: for example a database client "shadow process" may have its own handling, may change its own process group, and/or on termination may have an unexpected effect on the parent. Additionally modifying the priority of children can have unexpected results in these cases as well. - I recall that signal handling in general requires a lot of care due to the asynchronous nature of signals. - I recall that process and group permissions are a tricky area, some capabilities require sudo authority and some children are better off running as different users, but the other side of the problem is preventing malicious use of the capabilities. On Jun 23, 2004, at 3:56 AM, Angus Leeming wrote:
Gregory Colvin wrote:
namespace {
std::map<pid_t, int> completed_children;
int status; sig_atomic_t pid;
}
extern "C" void child_handler(int) { pid = wait(&status); std::map<pid_t, int>::iterator it = completed_children.find(pid); if (it != completed_children.end()) it->second = status; }
I'm pretty sure that the above is safe code.
It's unsafe because it's not reentrant.
Really? I thought that Posix guaranteed that a handler receiving only one type of signal (SIGCHLD in this case) would not receive multiple calls simultaneaously? Is this not true in the presence of threads?
But why do you need to reap the zombie? I've implemented the java process control natives with no need for reaping.
Addressed elsewhere.
Angus
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost