保护主线程免受工作线程中的错误的影响

Question

When using posix threads, is there some way to "protect" the main thread from errors (such as dereferenced null pointers, division by zero, etc) caused by worker threads. By "worker thread" I mean a posix thread created by pthread_create().

Unfortunately, we cannot use exceptions - so no "catch", etc.

Here is my test program (C++):

void* workerThreadFunc(void* threadId) {
  int* a = NULL;
  *a = 5; //Error (segmentation fault)
  pthread_exit(NULL);
}

int main() {
  cout << "Main thread start" << endl;

  pthread_t workerThread;
  pthread_attr_t attr;
  pthread_attr_init(&attr);
  pthread_attr_setdetachstate(&attr, PTHREAD_CREATE_JOINABLE);
  pthread_create(&workerThread, &attr, workerThreadFunc, (void*)0);
  pthread_join(workerThread, NULL);

  cout << "Main thread end" << endl;
}

In the example above, the error caused by workerThread will terminate the whole program. But I would like the main thread to continue running despite this error. Is this possible to achieve?

Answer 1

Sounds to me like you should be using multiple processes, not threads. Independent processes are automatically protected from these sort of errors happening in other processes.

You can use pipes or shared memory (or other forms of IPC) to pass data between threads, which has the additional benefit of only sharing the memory you intend to share, so a bug in the worker "thread" cannot stomp on the stack of the main "thread", because it's a separate process with a separate address space.

Threads can be useful, but come with several disadvantages, sometimes running in separate processes is more appropriate.

Answer 2

The only way I can think of doing this is registering a signal handler, which could instead of aborting the program, cancel the currently running thread, something like this:

void handler(int sig)
{
    pthread_exit(NULL);
}

signal(SIGSEGV, handler);

Note, however, this is unsafe as pthread_exit isn't listed as one of the safe system calls inside a signal handler. It might work and it might not, depending on the O/S you're running under, and on what signal you're handling.

Answer 3

Assuming your system uses signals in a POSIX sort of a way (though that may fall under the "no exceptions" rule), then POSIX says:

At the time of generation, a determination shall be made whether the signal has been generated for the process or for a specific thread within the process. Signals which are generated by some action attributable to a particular thread, such as a hardware fault, shall be generated for the thread that caused the signal to be generated.

So you can handle SIGSEGV , SIGFPE , etc. on a per pthread basis (but note that you can only set one signal handler function for the entire process). So, you can "protect" the process from being stopped dead by a failure in a single pthread... up to a point. The problem, of course, is that you may find it very difficult to tell what state the process -- the failed pthread, and all the other pthreads -- is in. The failed pthread may be holding a number of mutexes. The failed pthread may be leaving some shared data structure(s) in a mess. Who knows what sort of a tangle things are in -- unless the pthreads are essentially independent. It may be possible to arrange for other pthreads to close down "gracefully"... rather than crash and burn. It may, in the end, be safer to stop all pthreads dead, rather than try to continue in some less than well defined state. It will depend entirely on the nature of the application.

Nothing is for nothing... threads can communicate with each other more easily than processes, and cost less to start and stop -- processes are less vulnerable to failure of other processes.