> I'd like to know how else, other than this ugly SIGCHLD handler, you > can create a child process without having the keep track of the pid > and have part of your code be responsible for waiting for it.
But it *is* necessary to keep track of the pid! fork() returns a pid for a reason; good programming practice is for the SIGCHLD handler to wait (with W_NOHANG) for zombies, call a possible termination routine if the pid is in the list of known children pids, and *do absolutely nothing* if it is not. Or maybe your point was that the main SIGCHLD handler has to wait for all children anyway, so it is impossible for library code to do the waitpid() for forked processes? Well, yes, that is right, library code cannot rely on a waitpid() to detect child termination. It has to use another mechanism and let the reaping be handled by the main SIGCHLD handler. Fortunately, there is a trivial mechanism to detect child termination: pipes reading from the child read EOF when the child is dead. That is how library code can forkexec helper programs without any trouble. > I've timed it. fork() takes as least twice as long as pthread_create > and that's including the time pthread_create spends on mmap, mprotect, > etc. That's still a puny price to pay for the protection that separate processes offer. > I already explained how this could lead to *unbounded* memory growth > through leaks that are nearly impossible to fix, unless all your > forking happens from a common parent that doesn't grow. You keep opposing badly written multiprocess code to well-written multithreaded code. Let's not go down that road, because I have seen the horrors that come from badly written multithreaded code and there is no way you can deny it's the worst nightmare ever. Correctly written multiprocess code forkexecs from a single parent unless there's a very good reason to do otherwise, and does not arbitrarily fragment memory. -- Laurent _______________________________________________ busybox mailing list [email protected] http://lists.busybox.net/mailman/listinfo/busybox
