CODEWITHSUNDEEP
cmultithreadingpthreadsfork
Kobi
Kobi

Reputation: 1495

How to handle a fork error for a multithreaded process?

I am working on a multithreaded process that forks to execute another process. Sometimes, the fork may error if the execution file does not exist. Since this process has multiple threads running prior to fork I have a couple questions:

  1. Are threads copied over to the forked process.

  2. What is the best practice to handling an error from fork with a multithreaded process. For example:

    /* in a multithreaded process */


pid = fork();

if(pid == 0)
{

    execlp(filename, filename, NULL);

    fprintf(stderr, "filename doesn't exist");

    /* what do i do here if there's multiple threads running
    from the fork? */

    exit(-1);
}

Upvotes: 1

Views: 1852

Answers (1)

paxdiablo
paxdiablo

Reputation: 881423

Well, the fork doesn't error if the executable file doesn't exist. The exec errors in that case. But, to your actual question, POSIX states that fork creates a new process with a single thread, a copy of the thread that called fork. See here for details:

A process shall be created with a single thread. If a multi-threaded process calls fork(), the new process shall contain a replica of the calling thread and its entire address space, possibly including the states of mutexes and other resources.

Consequently, to avoid errors, the child process may only execute async-signal-safe operations until such time as one of the exec functions is called.

So what you have is okay, if a little sparse :-)

A single thread will be running in the child and, if you cannot exec another program, log a message and exit.

And, in the rationale section, it explains why it was done that way:

There are two reasons why POSIX programmers call fork(). One reason is to create a new thread of control within the same program (which was originally only possible in POSIX by creating a new process); the other is to create a new process running a different program. In the latter case, the call to fork() is soon followed by a call to one of the exec functions.

The general problem with making fork() work in a multi-threaded world is what to do with all of the threads. There are two alternatives. One is to copy all of the threads into the new process. This causes the programmer or implementation to deal with threads that are suspended on system calls or that might be about to execute system calls that should not be executed in the new process. The other alternative is to copy only the thread that calls fork(). This creates the difficulty that the state of process-local resources is usually held in process memory. If a thread that is not calling fork() holds a resource, that resource is never released in the child process because the thread whose job it is to release the resource does not exist in the child process.

When a programmer is writing a multi-threaded program, the first described use of fork(), creating new threads in the same program, is provided by the pthread_create() function. The fork() function is thus used only to run new programs, and the effects of calling functions that require certain resources between the call to fork() and the call to an exec function are undefined.

Upvotes: 4

Related Questions