问题
We are working on a multithreaded memory-consuming application written in C++. We have to execute lots of shellscript/linux commands (and get the return code).
After reading that article we clearly understood that it would be a bad idea to use system() in our context.
A solution would be to fork after program starts and before creating any threads but the communication with that process may not be easy (socket, pipe ?).
The second solution we considered may consist of a dedicated deamon written in python (using xinetd ?) that would be able to process our system calls.
Have you ever had that problem? How did you solve it?
Note : Here is a more complete article that explain this problem : http://developers.sun.com/solaris/articles/subprocess/subprocess.html They recommend to use posix_spawn which uses vfork() instead of fork() (used in system()).
回答1:
The article you link to mostly talks about issues if you fork() and don't immediately follow it with an exec*(). As system() typically would be implemented by a fork() followed by exec() most of the issues don't apply. One issue which does apply is the point about closing file descriptors, though; Unless you have specific reasons to do otherwise, opening files with O_CLOEXEC by default is probably a good rule of thumb.
One issue with fork()+exec() of large memory consuming applications is that if your OS is configured to not allow memory overcommit, the fork() may fail. One solution to this is to fork an "external process handler" process before you start allocating a lot of memory in your main process.
The best solution is if the functionality you require is available as a library, obviating the need to fork in the first place. That probably doesn't warm your heart in the short term, though.
回答2:
You will got questions for how you should call an external program (fork/exec/wait, how else), but it's only one part of the problem. The real issue is the scheduling of this, I assume, you don't want to run too many external programs parallel.
Without knowing how does thread organizing go in your system, I can warn you for two issues.
It's an important issue is to keep the load low by limiting external command/script call. You may set up a parameter, which tells, how many parallel external command should run at same time. Before you call an external command, you should increase a variable which shows the number of the active external processes; if it exceeds the limit parameter, sleep() some and try again. After the process finished, decrease that variable. (Increasing and decreasing must be mutexed.)
Another issue is, when you're using an external program, managing its lifetime. You should set up a "timeout" for each external process, and kill it, if it hangs for a while. There should be a "timeout" thread (or is should be the main thread), which controls others.
回答3:
How about this solution:
fork() at the very start of your program, and make the child dedicated to starting and managing your outside programs. Then have the parent start all of its threads and do the application logic, sending requests over a pipe when it needs an outside process.
This would step around the problems with threads as you fork before starting them.
来源：https://stackoverflow.com/questions/8574815/calling-system-from-multithreaded-program