Handling process exit from within a thread in a multi-threaded application

I have a multithreaded application. The application has the following set of thr开发者_StackOverflow社区eads:

1. The main thread that sleeps. All signals are blocked in this thread.

2. Thread t1 that does all the processing. All signals are blocked in this thread.

3. A signal handling thread (t2) setup by a third party component that I use. This thread waits only for the SIGINT and SIGKILL signals. all other signals are blocked in this thread.

4. My own custom signal handling thread (t3).

Now, for handling the process exit, I was sending a SIGUSR1 to my process. The signal would get caught by thread t3. Thread t3 would call the cleanup routine and exit. The problem here is that thread t3 tries to cleanup resources accessed by the other threads. This would result in intermittent crashes.

Obviously, my present solution does not have a graceful process exit handling. My question is how should one go about handling the process exit in such a scenario? How should the signal handling thread go about stopping the remaining threads and then doing a process exit?

Or is there a better way than sending signals (SIGUSR1) for process termination?

My application is written in C and runs on RHEL 5.

Put a mutex on the cleanup routine so two threads don't try to clean up at once. The thread that wants to shut down should acquire the mutex and then tell other threads to shut down (whichever way you normally do that). This way only one thread should ever do the actual cleanup.

void cleanup()
{
    pthread_mutex_lock(m);
    if (!cleanup_done) {
        cleanup_done = 1;
        tell_other_threads_to_stop();
        wait_for_other_threads_to_finish();
        clean_up_common_resources();
    }
    pthread_mutex_unlock(m);
}

Alternatively you can lock all shared resources permanently, clean them up and terminate the entire process while holding the locks.

One good way to handle signals in a multi-threaded application is to have only one thread wait for signals, all other threads should have signals blocked. Normally, this is the main thread that initializes all components/libraries, creates other threads, waits for signals and terminates the application in an orderly fashion.

It is not clear why your application has threads 1 and 4. Thread 2 can do all the work and handle all signals (should probably be the main thread). Generally, it is not a good idea to let a third party component handle signals, so it may be better to block signals in thread 3.

The standard termination signals an application should handle are SIGINT (sent upon ctrl-c keystroke) and SIGTERM sent by kill <app-pid>.

Your t3 has to cancel t1/t2 and wait for their terminations before calling exit() since race conditions exist here.

Don't be lazy in this situation because there are no other ways.

By the way, since your main() does nothing, you can simply finish it early with an explicit pthread_exit().