I'm trying to write a program which needs to create some other processes. I'm used to the Windows API but now I need my program to be able to run in a Linux platform too.
Is it possible to do it in a portable manner? Do I have to use the preprocessor for that purpose?
EDIT: I need to wait for it to finish before continuing to do things.
In my opinion the system function should always be avoided: it's unreliable, since you don't know what shell will handle your command and it doesn't have means to return you an unambiguous error code. Moreover, on platforms like Windows where processes are quite heavyweight it's not a good idea to launch a new process just to launch another one, and, by the way, some security suites may emit a warning for each process your app tries to launch, and doubling this notice (one for the command interpreter, one for the app actually launched) may doubly annoy the user.
If you just need to create a new process, you may just create your wrapper function around the actual platform-specific code, that will be selected automatically when the program will be compiled thanks to the preprocessor. Something like this:
int CreateProcess(const char * Executable, const char * CommandLine)
{
#if defined (_WIN32)
return CreateProcess(Executable, CommandLine /* blah blah blah */)!=FALSE;
#elif defined (_POSIX)
/* put here all the usual fork+exec stuff */
#else
#error The CreateProcess function is not defined for the current platform.
#endif
}
By the way, the function can be expanded easily to be blocking, you may simply add a flag (int Blocking, or whatever is now used in C99 for the booleans) that will trigger a WaitForSingleObject for the win32 section and a waitpid for the POSIX section.
The APIs are different, so there's no way around either writing two pieces of code or linking to a library which does the same.
The Apache Portable Runtime is a good option for writing portable low-level programs in C.
How much control over the other threads do you need? If it is a simple matter of just starting them, then the system() function is probably a good fit. If you want more control over them, I'd look into a library. I know that Qt makes it fairly easy to do some aspects of multi-process programming.
Try system() as it exists on both Posix and Windows.
#Jeff - system() is a blocking call, it will not return until the child process exits.
Related
I am new to C programming. I used to think using exit() was the cleanest way of process termination (as it is capable of removing temporary files, closing open files, normal process termination...), but when I tried man exit command on the terminal (Ubuntu 16.04.5, gcc 5.4.0) I saw the following line:
The exit() function uses a global variable that is not protected, so
it is not thread-safe.
After that I tried to make some research about better replacement for exit() (to change my programming behavior from the beginning). While doing that I faced with this question in which side effects of exit() is mentioned and it is suggested to use atexit() properly to solve the problem (at least partially).
There were some cases in which using abort() was preferred over exit(). On top of that, this question suggests that atexit() might also be harmful.
So here are my questions:
Is there any general and better way of process terminating (which is guaranteed to clean like exit() and is not harmful for the system at any case)?
If the answer to the first question is NO!, what is the best possible way of process terminating (including the cases in which they are most useful)?
what is the best possible way of process terminating
If going single threaded just use exit(), as your code is not going multi-threaded.
Else make sure all but one thread have ended before the last thread and then safely call exit() because of 1. above.
Given that power/hardware fails can happen at any time, the imposs.. extreme difficulty of reliably terminating threads with user code and the chaotic nature of the use of memory pools etc. in many non-trivial multithreaded apps, it is better to design apps and systems that can clean temp files etc. on start-up, rather than trying to micro-manage shutdown.
'Clean up all the resources you allocate before you exit' sounds like good advice in a classroom or lecture, but quickly becomes a whole chain of albatross round your neck when faced with a dozen threads, queues and pools in a continually changing dynamic system.
If you can, if you are running under a non trivial OS, let it do its job and clean up for you. It's much better at it than your user code will ever be.
I've been looking at creating Unix dæmons, and there seem to be two methods. The long-winded one, which seems to come up when searching is to call fork(), setsid(), fork() again, chdir() to somewhere safe, set umask() and, finally, close() stdin, stdout and stderr.
Running man daemon, however, brings up information on a daemon() function, which seems to do all the same stuff as above. Are there any differences between the two approaches or is daemon() just a convenience function that does the same thing as the long-winded method? Is either one better, especially for a novice C programmer?
The daemon function is not defined in POSIX, so its implementation (if any) could behave differently on different platforms.
On Linux with glibc, daemon only does one fork, optionally chdirs (but only to /, you can't specify a path), does not touch umask, and does not close the std* descriptors (it optionally reopens them to /dev/null though). (source)
So it depends on the platform, and at least one implementation does less than what you do. If you need all of what you're doing, stick with that (or stick to a platform where the daemon function does exactly that).
Note that daemon is not conforming to any standard. Better use standard conforming functions (like POSIX-defined fork and setsid).
The daemon call summarizes the long-winded fork procedure, and I don't recall any implementation that does anything more.
Since daemon() is a high-level concept, it's definitely to be preferred for novice and experienced programmers.
I develop a C code on Linux and I would like to execute a binary say /usr/sbin/binary_program -p xxx, Is there another way than system() call to execute a binary?
Yes, and in general, system should never be used, for at least these reasons:
It suffers from all the dangers of shell quoting issues, so anything but a hard-coded command line is potentially dangerous.
It is not thread-safe.
It interferes with signal handling in the calling program.
It provides no way to get output from the executed program except for the exit status, unless the command explicitly saves output to a file.
For executing external programs, you should use posix_spawn, or fork followed by one of the exec-family functions. However, if possible you should avoid dependency on external programs/commands, especially when it would be easier and less error-prone to do the work directly in your program. For example I've seen ridiculous usages like system("sleep 1"); instead of sleep(1);.
Yes, you can use the exec* family of functions.
http://pubs.opengroup.org/onlinepubs/9699919799/functions/execv.html
If needed to simulate the behavior of system you can fork and then call an exec function.
The POSIX page of system says:
The system() function shall behave as if a child process were created using fork(), and the child process invoked the sh utility using execl() as follows:
execl(< shell path>, "sh", "-c", command, (char *)0);
It is important to realize that you can have several programs running simultaneously, and communicating thru pipes (or others Inter Process Communication). This is mostly possible thru a mixture of syscalls.
I strongly suggest reading Advanced Linux Programming, or some other good books explaining a lot more (than we can do in a few minutes) about various syscalls(2) involved, notably fork(2), pipe(2), dup2(2), execve(2), waitpid(2) and several others (perhaps poll(2) for multiplexing, e.g. to avoid deadlocks in circular pipes). The system(3) function is built above these syscalls (and /bin/sh)
That Advanced Linux Programming book has an entire chapter devoted to processes.
I also suggest to understand how a Unix command shell works. Either by studying the source code of some simple free shell (like sash) or at least by strace-ing it.
Practically speaking, popen(3) is more useful then system(3). You can get the output of the companion command.
Some libraries (Poco, Qt, Glib/GTK) also have powerful process management functions.
A new process is created with fork which is tricky to understand. A new program is started in the same process with execve.
All processes are created by fork (or perhaps vfork) except some few started magically by the kernel (/sbin/init, /sbin/modprobe, ...)
I'm trying to run an application in C, but the only way I could find that is reasonably easy to use works like this:
system("command here");
It works, of course, but it's really slow (especially when repeating this a lot). I'm just wondering if there is a way of running a program without having to interact with a shell, something like python's subprocess module.
I have heard of execl, and I would use that (forking it first, of course), but I'm wondering if there is a simpler way that wouldn't require forking first.
EDIT: I also want to be able to know the return code of the program
As I'm sure you already know, system already employs the fork/exec strategy. I understand you want to circumvent the shell and are looking for a simple approach, I'm just saying you could just as easily write a function to wrap the fork/exec pattern as is done in system. Indeed it would probably be most straightforward to just do that. An alternative as Gabe mentioned in the comments is posix_spawn.
A faster (but apparently discouraged) alternative is vfork() / exec, but this is generally discouraged and is obsolete in the latest POSIX standards.
4.3BSD; POSIX.1-2001 (but marked OBSOLETE). POSIX.1-2008 removes the
specification of vfork().
It's meant to be immediately followed by an exec or _exit. Otherwise all kinds of weird bugs can arise since the virtual memory pages and page tables aren't duplicated (child uses same data/heap/stack segments). The parent/calling process blocks until the child execs or _exits. Regular fork's modern implementations have copy-on-write semantics which approach the speed of vfork, without the potential bugs incurred by vfork's memory sharing semantics.
If you want even further control over memory-sharing semantics and process inheritance, and the consequent potential speed-up (and are on Linux), look into clone() (wrapper for system-call sys_clone()) which is what some process-creating system calls delegate their work to. Be sure to carefully comb over all of the various flags.
You can use waitpid to get the exit status of the process.
If neither system() nor popen() provides the mechanism you need, then the easy way to do it is with fork() and execv() (or, perhaps, execl(), but the argument list must be fixed at compile time, not variable, to use it). Really! It is not hard to do fork() and exec(), and any alternative will encapsulate that processing.
The Python subprocess module is simply hiding fork() and exec() for you behind a convenient interface. That's probably appropriate for a high-level language like Python. C is a lower-level language and doesn't really need the complexity.
The hard way to do it is with posix_spawn(). You have to create arguments to describe all the actions you want done in the child between the fork() and the exec(), which is far harder to set up than it is to simply do the fork(), make the changes, and then use exec() after all. This (posix_spawn()) is what you get when you design the code to spawn a child process without visibly using fork() and exec() and ensure that it can handle almost any reasonable circumstance.
You'll need to consider whether you need to use wait() or waitpid() or a variant to determine when the child is complete. You may need to consider whether to handle the SIGCHLD signal (which will notify you when a child dies).
I want to call one command(user defined) from C program(Windows).
Can you tell me the function available?
system() is the simplest way to call external programs.
It's a matter of doing something like:
system ("runme.exe");
The Win32 API has a lot of process control calls as well, which give you better control and monitoring. Look for CreateProcess and its brethren.