Executing another program from C++ with specified running timeout - c++

I'm writing a program (A genetic algorithm implementation) which executes another program using "system" method to calculate fitness. The problem is that another program sometimes hangs for unlimited amount of time. How can I execute a program with some time limit from C++.
Both POSIX and c++ solutions are appreciated. And more or less this will be run once application so solution doesn't have to be very elegant.
I'm running Linux CentOS distribution and am testing on Cygwin. For compiler I use gcc 4.1.2 with boost library.
Any help is apreciated

Instead of system, execute the program with the fork/exec idiom. Before the exec, set RLIMIT_CPU to a maximum value with setrlimit in the child.
Make sure the child does not ignore SIGXCPU (which is very unlikely).

You could create a timer (with boost timer for example) and then try to kill the child process... this assume that you use fork and exec to launch all your child, and you stored each pid.

If this 'another' program is yours or you have sources under public license it's better probably to make it not a separate program but a separate thread in the main program. In this case you can easily control it.
If this 'another' program is yours or you have sources under public license but don't want (or can't) follow the suggestion above may be it is easier to fix the program to prevent hanging.
Shitty method:
do fork(), remeber PID, call exec*("my-prog", ...)
create thread in the main program with timer.
when time fires kill the process using kill() and PID remembered.

Related

Multithreaded program and fork(): alternative or safe implementation

In a multithreaded Linux/C++-program, I want to use fork() with a signal handler for SIGCHLD.
In the child process I use open() to create two new file descriptors, sendfile() and close(), then the child exits.
I planned to use fork() to implement the following requirements:
The threads in the parent process shall be able to
detect the normal termination of the child process, and in that case shall be able to create another fork() doing the open()/sendfile()/close() for a range of files
kill the sendfile()-child process in case of a specific event and detect the intentional termination to clean up
For requirement 1 I could just wait for the result of sendfile().
Requirement 2 is why I think I need to use fork() in the first place.
After reading the following posts
Threads and fork(). How can I deal with that?
fork in multi-threaded program
I think that my solution might not be a good one.
My questions are:
Is there any other solution to implement requirement 2 ?
Or how can I make sure that the library calls open(), close() and sendfile() will be okay?
Update:
The program will run on a Busybox Linux / ARM
I've assumed that I should use sendfile() for having the most efficient file transfer due to several posts I've read regarding this topic.
A safe way to implement my requirement could be using fork() and exec*() with cp, with the disadvantage that the file transfer might be less efficient
Update 2:
it's sufficient to fork() once in case of a specific event (instead of once per file) since I switched to exec*() with rsync in the child process. However the program needs invoke that rsync always in case of a specific event.
You can use threads, but forcefully terminating threads typically leads to memory leaks and other problems.
My linux experience is somewhat limited, but I would probably try to fork the program early, before it gets multithreaded. Now that you have two instances, the single threaded instance can be safely used to manage the starting and stopping of additional instances.

Run two programs at the same time C/C++

I was reading this article about Inter-Process communication with message passing. In order to run the examples and see the it says and I quote: "should be compiled and run at the same time". Someone has any ideas how exactly should I do this?
You can create BAT file and start both programs almost simultaneously:
START first.exe
START second.exe
"should be compiled and run at the same time"
I think it is clear a program can not be run until after it is compiled (this is a minor grammatical issue, and should be ignored).
In Linux, my preferred mechanism to launch a process is popen invoked by my C++ program.
In C++, it is easy for one thread (let us call this your start process) to use popen to launch as many processes as needed for your application (call these work processes).
I would then use messages to synchronize the start up (i.e. work processes should initialize themselves, then wait (at startup) for a go message from start process). These start up messages work in the same way your application would use them. This ensures that the multiple work processes are running at the same time (but within the constraints of how many cores your system has available).

Launch Executable from Secondary thread

I need a way to launch executable (process) from secondary thread. The wxWidgets toolkit I use give me no way to the best of my knowledge and now I have to seek platform dependent way (Linux and Windows only) way to do that.
The executable will read and write to the file. Other than knowing that the process is still running or not (and if possible exit code) there is no much this thread is going to do with process itself. After process terminate, the thread will read the written file, analyze it and send result to GUI thread for displaying. I have no idea how to do it since I have been depending on wxExecute all the times.
Do you really want separate processes, or will threads do.
To get separate processes, you need fork() for Linux and CreateProcess() for Windows. The best approach is often to make a function to encapsulate it.
bool RunProces(const std::string &sCmdLine)
{
#if defined(WIN32)
// launch with CreateProcess() ...
#else
// launch with fork() ...
#endif
return bSuccess;
}
If, however, you can just use threads, you can use the portable std::thread class.
An alternative approach is to use popen() (_popen() for Windows). This launches a new process and redirects its output (stdout) to a pipe. You can then read the pipe to retrieve the sub-process output.
A couple of notes about popen():
Redirecting the standard output makes it impractical for the sub-process to interact with the user.
There would be some overhead setting up the pipe. Probably not important unless you are spawning large numbers of sub-processes.
I've never seen popen() used to launch a non-console Windows program (with no main() function). I wouldn't be surprised if there are problems doing that.
You will have to move quite a few parts of your code from the secondary thread to the main thread. The wxWidgets documentation you refer to says it all:
When a wxProcess object is passed to wxExecute(), its OnTerminate()
virtual method is called when the process terminates. This allows the
program to be (asynchronously) notified about the process termination
and also retrieve its exit status which is unavailable from
wxExecute() in the case of asynchronous execution.
And below:
Currently wxExecute() can only be used from the main thread, calling
this function from another thread will result in an assert failure in
debug build and won't work.
So, you need to eliminate the need to call wxExecute from the secondary thread. How exactly you should do this depends on your application, but it will probably involve the secondary thread sending a custom wxWidgets event to the main thread using wxQueueEvent. The main thread then handles the event by calling wxExecute in asynchronous mode and retrieving its result later on.
Now what to do with the result?
Ideally, you rework your application logic such that the secondary thread does not need the result but instead:
the main thread handles it all by itself, -or-
another secondary thread is started and handles it.
This will minimize the amount of synchronization you have to do, and thus reduce the probability of hard-to-find concurrency programming errors.

Lauch a program in the background

I've been trying to launch and close an external program at certain point during my code, and was relying on system() calls to accomplish that. However, here it was suggested that I use execlp and a separate std::thread entirely, in order to suppress console outputs.
The problem is, both of these solutions imply waiting for the program to close, which I want to avoid, as I need to communicate with that program (right now through UNIX sockets). Is there any way to use either execlp or std::thread to lauch a program in background, as I do with system([program]&)?
actually you can use threads :) but with care...
the simplest way to do fork before spawning any thread in parent/all process/es. then, after fork you may start any needed threads (anywhere you want: in parent as well as in child process).
doing fork there is no threads started automatically in a child process, but I suppose you don't need them... child usually do some preparations and exec required process, so you don't need to respawn any threads in it. (anyway if you want, you can do it!). then, you have to watch your child via waitpid and wait for it's death.
PS: also read man pthread_atfork if you really need some threads in a child.

to system() or fork()/exec()?

There appear to be two common ways of running an external executable from C in unix, the
system()
call and
pid = fork()
switch(pid)
//switch statement based on return value of pid,
//one branch of which will include and exec() command
Is there any reason to prefer a fork/exec over system in the case where they are functionally equivalent (parent process waits for child to finish, no complex information is returned from child)?.
system executes a command-interpreter, i.e. a shell, which (a) is slower than a direct fork/exec, (b) may behave differently on different systems and (c) is a potential security hazard if you pass it a string from an untrusted source. Also, system waits for the child process to exit, while you might want it to run concurrently with the parent process.
More in general, the low-level fork/exec gives you additional control: before or in between the two operations, you might want to chdir, open pipes, close file descriptors, set up shared memory, etc.
(By different systems, I don't mean Windows vs. Unix (as Windows doesn't even have fork): I'm talking Red Hat Linux vs. Ubuntu. The former uses Bash to execute what is passed to system, the latter a lightweight POSIX-compatible shell.)
fork() creates a new process. If you don't need to do that, just use system() (or popen()). You might want a second process to achieve parallelism, or for finer-grained control over the job, but often you just don't care for that if the job is meant to be synchronous.
On the other hand, I find that 95% of uses of system() are unnecessary or would somehow be better off done another way (e.g. using zlib instead of system("gzip")). So maybe the best answer is to use neither!
Going via system() additionally invokes a shell process, which might not be what you want.
Also the calling process is notified only when such shell dies not when the actual process run by the shell died.
system() will type out the command and execute it like a user would have typed out.
i mostly saw it like system("pause"); system("cls");
But if you need to control the child process, you want to fork.