std::thread - "terminate called without an active exception", don't want to 'join' it

Question

As per This Question, I'm using a thread to terminate a function on user input. My code looks something like:

bool stopper = false;
thread stopThread(userStop, &stopper);      // start thread looking for user input
for(int i = 0; i < 1000; i++) {
    if(stopper) { break; }                  // break if desired
    // Do stuff
}
return 0;

where,

userStop(bool *st) {
    char chChar = getchar();
    if(chChar == '\n') {
        *st = true;
    }
}

When I run this, I get the error terminate called without an active exception. Based on these questions: thread terminate called without an active exception, C++ terminate called without an active exception; it looks like its because I'm not 'join'ing the thread again.

The problem is, I don't want to 'join' the thread -- because then the user will need to provide input for userStop()to terminate, but I only want the user to provide input if the for-loop is to be broken (which it isn't necessarily).

Thanks!

Answer 1

The trouble you are encountering is a result of the stopThread going out of scope on the stack. The C++ standard has the following to say about this:

30.3.1.3 thread destructor [thread.thread.destr]

~thread();

If joinable() then terminate(), otherwise no effects. [ Note: Either implicitly detaching or joining a joinable() thread in its destructor could result in difficult to debug correctness (for detach) or performance (for join) bugs encountered only when an exception is raised. Thus the programmer must ensure that the destructor is never executed while the thread is still joinable. — end note ]

What this means is that you should not let threads go out of scope without first calling either join() or detach().

The way you describe it, you want the thread to go out of scope without joining so it will continue to run as your application runs. That requires a call to detach(). From there, I can only offer a little wisdom...

• That thread is now completely responsible for its own lifetime. If it doesn't return on its own, it will run forever (until the process terminates).

• You are getting user input, presumably from something like cin or getch(). If these are accessed from multiple threads, you do not have much assurance that there are not race conditions in their library implementations. Tread lightly.

Answer 2

In your standard input thread, you'll want to asynchronously read from input. And wake up on both a demand to stop reading, and new input.

Terminating a thread without joining is not a reasonable thing to do. So what you need to be able to do is say "yo thread, finish up right now", then be able to expect that the join will finish promptly. This can even be via a two-step handshake ("yo thread, finish up", followed by "ok ok, I managed to clean up, join me now") in some cases.

Note that your loop to 1000 looks really ridiculous: user input timeouts should generally be based on actual time passing, or some other event occurring that makes the user input non-useful.

Answer 3

Terminating a thread is a bad idea -- you should make your thread exit gracefully. If you did terminate the thread, you'd end up causing code in the getch() function to end unexpectedly. What if that code was in the middle of managing a data structure, allocating or freeing memory, or doing some other work that had to execute until completion? You'd end up leaving something in an invalid state, and you'd eventually crash when that invalid state was exercised.