What to do with std::thread after it was killed?

Question

Suppose we have a threaded program. We create some resources (i.e. mutexes), spawn threads that do their own initialization, wait for them to finish, then destroy resources.

void run(void)
{
    some_resource global_resource;
    global_resource.create();

    vector<thread> my_threads;
    my_threads.reserve(thread_count);

    for(int i = 0; i < thread_count; i++)
        my_threads.push_back(
            thread([&global_resource](int i)
            {
                another_resource local_resource;
                local_resource.create();

                // SIGTERM can happen here:
                work_with_resources(global_resource, local_resource, i);

                local_resource.destroy();
            },
            i)
        );

    for(int i = 0; i < thread_count; i++)
        my_threads[i].join();

    global_resource.destroy();
}

Now suppose that one of the threads, sadly, received SIGTERM during work_with_resources(). That means the local resource of the thread will never be destroyed.

Question 1: What to do to keep track of resources? Is it possible to destroy the killed thread's local resource?

Question 2: Is the thread after being killed still joinable? Will the join() method return immediately? Is join()ing with the killed thread a good practice?

Question 3: Since the killed thread might have used the global resource, it may be left in invalid state. Is there a way to stop all other threads from using the global resource to prevent further damage?

Does the C++ thread library cooperate with signals at all?

You can handle and ignore SIGTERM, but why does that occur to begin with? Are you terminating your own threads on purpose? — Baum mit Augen, Feb 15 '18 at 17:20
[I attempted this once; it was horrid](https://codereview.stackexchange.com/q/9431/2503). I think I (eventually) decided not to bother. — Lightness Races in Orbit, Feb 15 '18 at 17:28
SIGTERM usually kills a *process* not just one of its threads. — Jesper Juhl, Feb 15 '18 at 17:33
According to this answer you can't send a kill signal to an individual thread from a different process. So this should never crop up: https://unix.stackexchange.com/questions/1066/how-can-i-kill-a-particular-thread-of-a-process — Galik, Feb 15 '18 at 17:48

score 2 · Accepted Answer · edited Feb 15 '18 at 17:39

First of all SIGTERM behave differently with different version of POSIX library. In 2.6 SIGTERM will forced the thread to exit cleanly. But with 2.4 the thread will be in an indeterminate state.

Now your first question:-

Question 1: What to do to keep track of resources? Is it possible to destroy the killed thread's local resource?

You have no option to track of resources in this case and not possible to reach the thread anymore.

Now your second question:-

Question 2: Is the thread after being killed still joinable? Will the join() method return immediately? Is join()ing with the killed thread a good practice?

Simply no for all your question.

Now your third question:-

Question 3: Since the killed thread might have used the global resource, it may be left in invalid state. Is there a way to stop all other threads from using the global resource to prevent further damage?

You can use pthread conditional variable in this case (pthread_cond_t).

What to do with std::thread after it was killed?

1 Answers1