> A library cannot use popen without documenting this so the caller > knows. This is because a caller that's not expecting to have child > processes except the ones it creates might install a signal handler > for SIGCHLD that just immediately reaps all children if it doesn't > care about their exit status.
Such a caller is very badly coded. Reaping processes you do not know about should only be performed in very special cases, i.e. for instance, process 1. Good programming practices say that callers should reap exactly what they sow, no more, no less. If that rule is followed, there is no problem in having libraries fork(). I have written a few libraries that fork+exec an auxiliary ptogram, the library code essentially being a communication interface with that auxiliary program. I have never had any problems using those libraries in my main processes. If someone has trouble using a library that forks, the problem does not lie in the library, but in the SIGCHLD handler. > You might call such calling programs badly coded, but it's a common > idiom. Not so common. Unless they're all coded by people who believe that starting all their programs by blocking all signals except a few chosen ones is a good programming practice, see what I mean ? ;) > The alternative, if you want to make a "detached child process" > (one you don't have to keep track of and later wait for) is to "double > fork" It is a possibility, but it is not necessary. Also, the cost of fork() is not as high as you pretend it is. With COW, very few pages are copied at fork() invocation, and if the child dies or execs soon afterwards, no more copying happens. On Linux, fork() and pthread_create() are even based on the *same* system call, clone(), so the difference is really small if fork() does not have that much data to duplicate. > In short, processes are *not* easy to use. They have ugly corner > cases like this all over the place. Oh, please. Your arguments against multiprocessing are that processes are tricky to use and have ugly corner cases, and instead you are advocating the use of *threads* ? We must not be living in the same world. In my world, processes are MUCH easier to use than threads ! The inconveniences you mentioned are *nothing* compared to the headaches of properly synchronizing your threads, locking exactly what must be locked for the necessary duration, etc. When you use processes, the kernel protects you. It's on your side. The system calls are designed so that a sequence that should intuitively work actually works most of the time; there is no need for explicit synchronization, and if your shared data is accessed through the filesystem, file locking is easy to use. You have no such protection from the kernel when you use threads. You are on your own. Everything is fair game. Talk about ugly corner cases ! I guess most of it comes from practice and habit. I am very much used to multiprocess programming, and find it easy. You are probably very much used to multithread programming, that's why you find it easy. > That does not mean you have to use it at all. It's completely possible > to write a multi-threaded program where each thread never accesses any > object except its own automatic variables and memory it allocated > itself with malloc. Then you might as well use separate processes, and have the kernel guarantee your threads won't walk all over one another, at the cost of a little more memory and a little more CPU time at thread creation. That is a small price to pay for a guarantee of correctness. The whole point of using a multi-threaded program is when you have to access shared structured data that multiple processes would have trouble sharing. -- Laurent _______________________________________________ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
