Can I fork processes and exec internal functions? - c

Question

I've really searched for this and all I can find is that you can execvp() shell commands.
I'm wondering if I can fork processes and then have them run a function that's internal to the program? (As in, a function I've written myself within the code)

Answer 1

Of course you can have the child execute one function and the parent execute a different (or even the same) function in the same executable.
pid_t pid = fork();
if (pid < 0)
err_syserr("failed to fork: ");
else if (pid == 0)
be_childish();
else
be_parental();
You can add arguments to be_childish() and be_parental() as needed. Before the code executes fork(), you can create pipes or sockets to communicate between them — or semaphores, and shared memory, or whatever IPC you want.

Answer 2

When you call fork, a new process is created inheriting the current context of the parent process. The child and parent processes can execute independently calling any function within your program. However, if they need to communicate/synchronize with each other, they need to use one of the IPC mechanisms such as shared memories, pipes, semaphores etc.

Answer 3

I suspect the simplest answer here is an example:
#define _POSIX_C_SOURCE 200809L
#include <stdlib.h>
#include <unistd.h>
#include <sys/types.h>
#include <sys/wait.h>
#include <string.h>
#include <stdio.h>
#include <errno.h>
static int child_foo(void)
{
/* This child process just counts to three. */
int i;
for (i = 1; i <= 3; i++) {
printf("Foo: %d\n", i);
fflush(stdout);
sleep(1);
}
printf("Foo is done.\n");
return EXIT_SUCCESS;
}
static int child_bar(unsigned long n)
{
/* This child process checks if n is prime or not. */
const unsigned long imax = (n + 1) / 2;
unsigned long i;
for (i = 2; i <= imax; i++)
if (!(n % i)) {
printf("Bar: Because %lu is divisible by %lu, %lu is not a prime.\n", n, i, n);
return EXIT_FAILURE;
}
printf("Bar: %lu is prime.\n", n);
return EXIT_SUCCESS;
}
int main(void)
{
pid_t p, foo, bar;
int status;
printf("Forking child processes.\n");
fflush(stdout);
foo = fork();
if (foo == -1) {
fprintf(stderr, "Cannot fork: %s.\n", strerror(errno));
return EXIT_FAILURE;
} else
if (!foo)
return child_foo();
bar = fork();
if (bar == -1) {
fprintf(stderr, "Cannot fork: %s.\n", strerror(errno));
/* Wait until all child processes (here, foo only) have completed. */
do {
p = wait(NULL);
} while (p != -1 || errno == EINTR);
return EXIT_FAILURE;
} else
if (!bar)
return child_bar(227869319);
/* Wait until all child processes have completed. */
do {
p = wait(&status);
if (p == foo || p == bar) {
/* Report exit status. */
if (p == foo)
printf("child_foo()");
else
printf("child_bar()");
if (WIFEXITED(status)) {
if (WEXITSTATUS(status) == EXIT_SUCCESS)
printf(" exited successfully (EXIT_SUCCESS).\n");
else
if (WEXITSTATUS(status) == EXIT_FAILURE)
printf(" exited with failure (EXIT_FAILURE).\n");
else
printf(" exited with status %d.\n", WEXITSTATUS(status));
} else
if (WIFSIGNALED(status))
printf(" died from signal %d (%s).\n", WTERMSIG(status), strsignal(WTERMSIG(status)));
else
printf(" was lost.\n");
fflush(stdout);
}
} while (p != -1 || errno == EINTR);
printf("All done.\n");
return EXIT_SUCCESS;
}
Above, main() forks two child processes. One of them runs child_foo() and exits, the other runs child_bar(227869319) and exits. The parent process reaps all child processes, and returns the cause of exit and exit status if available, then exits itself as well.
The fflush(stdout) before the fork() is there to remind that internal caches (including caching done by the C library) should be flushed before forking, or else the child process will inherit the cache contents. In the case of stdout, this would mean duplicated outputs.
In practice, it is often better for maintainability (human programmer understanding) to "return" from the child process functions using exit(EXIT_SUCCESS) or exit(EXIT_FAILURE), than return. Then, in main(), instead of say return child_foo(), you'd have say
child_foo(); /* Never returns. */
exit(EXIT_FAILURE);
where the exit(EXIT_FAILURE) is just a bug catcher, in case a modification to child_foo() causes it to return rather than exit.
In some cases the return pattern is useful, if there is cleanup work that must always be done before the child process exits. In that case, you usually put that cleanup work in a separate function, and then replace return child_foo() with
int exitstatus;
exitstatus = child_foo();
cleanup_function();
exit(exitstatus);
Note that in main(), return exitstatus; and exit(exitstatus); are exactly equivalent (C89 2.1.2.2, C99 5.1.2.2.3p1, C11 5.1.2.2.3p1). The only difference is to us humans; it may be easier for us humans to correctly interpret the intent behind exit(exitstatus) in the middle of main(), compared to return exitstatus;. Myself, I "parse" them the same, but I seem to use return more.
The strsignal() function is defined in POSIX-1.2008, and is only called if you manage to kill one of the child processes with an external signal without killing the parent as well. If your C library does not support it, just remove it (also remove the %s printf specifier, too).
As usual, the second most important thing to do, is to ensure future developers understand the intent correctly. I included pretty minimal comments, but both the function names and the initial comment in the child process functions should make the intent clear. I'm sure you can do even better. (I do consider commenting to be the hardest part in programming for me. It is so easy to write useless comments that describe what the code does, but omit the intent. When you look at even your own code months later, you forget your thoughts then, and must rely on the comments (and indirectly infer from the code) to get a proper understanding of the intent. Good comments are hard to write!)
In my opinion, the most important thing is to ensure the program is robust, and does not silently corrupt data. This means sufficient error checking (in my case, paranoid -- I really don't want to silently corrupt data) and minimal assumptions on what "ought to" succeed. Sometimes, it leads to "nests" of code, like the status checks in the wait() loop in main(). I deliberately left out the comments there, because I believe you should go through it, keeping a browser or terminal window open to man 2 wait, and add the necessary comments so you understand exactly what that nest of code does. It will definitely help you understand a lot about how processes can terminate or be terminated, and how a parent process can detect that.

Answer 4

You fork a process (a running, active, instance of a program) and you execve an executable (a passive file, usually in ELF format) - not some functions. Read again fork(2) and execve(2) and credentials(7). See also Operating Systems: Three Easy Pieces to understand better the role of an OS.
that you can execvp() shell commands.
Wrong. execvp calls execve and runs executables (not shell commands; e.g. you cannot execvp the cd shell builtin). It does not use the shell (but execvp search your PATH variable as your shell does).
Notice that every process has its own virtual address space. And fork creates a new process with its own new virtual address space (which happens to be a copy of the virtual address space of the parent. That copy happens lazily, read about copy-on-write techniques). execve is replacing the virtual address process by a new one (described in the executable file).
Since that new virtual address space (after a successful fork, in the child process) is a copy of the parent one, it also contains the code of every internal function you dream of from your program. So after a fork you can call these internal functions.
Use pmap(1) and proc(5) to understand the virtual address space of processes. At first, run cat /proc/$$/maps then pmap $$ in a terminal, and try to understand its output (it describes the virtual address space of your shell process).
When a process is running, you could extend its virtual address space using mmap(2). This is used by malloc, and also by dlopen(3) (which enables you to load plugins into your process).
PS. I am guessing you are using Linux.