Exit two-threaded program with user input?

[vincegata]

Hello,

// clang++ -g -std=c++11 main.cpp -pthread
#include <iostream>
#include <thread>
#include <unistd.h>

void thread1(void)
{
   while(1)
   {
      int i = 88 * 2;
      ::usleep(100000);
   }
   return;
}

void thread3(void)
{
      char ch = 0;
      while(1)
      {
            std::cin >> ch;
            if (ch == 'q') break;
      }
      return;
}

int main()
{
      std::thread th1(thread1);
      std::thread th3(thread3);
      th1.detach();
      th3.join();
      std::cout << "All done\n";
      return 0;
}

Thread1 does some background work, and thread2 is waiting for the user's input.

If I join thread1 then the app can never exit. If I neither join nor detach thread1 then I get "terminate called without an active exception Aborted" which is not a good thing to have.

If I do detach on thread1 does thread1 ever terminate?
If not, how to terminate it?
Also, how do I check if it's terminated or not? -- I realize it's platform specific, I am on Linux.

Thank you.

[OReubens]

Rule 1)
DO NOT
...
EVER EVER EVER ... (repeat 2048 times)
...
use console input on a thread other than the main thread.



Rule 2)
DO NOT
...
EVER EVER EVER ... (repeat 2048 times)
...
attempt to join a thread waiting for user input with other threads

---

the only thing you can do safely if joining threads on other threads where no user input is involved
or
you can safely join threads onto your main thread.


combining waiting for input with join() is going to need features not possible with the standard library.

[superbonzo]

If I neither join nor detach thread1 then I get "terminate called without an active exception Aborted" which is not a good thing to have.

this is by design, letting a joinable thread object to destroy will invoke terminate ( and for good reasons ), don't do that.

If I do detach on thread1 does thread1 ever terminate?
If not, how to terminate it?
Also, how do I check if it's terminated or not? -- I realize it's platform specific, I am on Linux.

You should either join and wait for it to finish or detach and use some other synchronization primitive to signal the "waiting" thread that is done, how you do it depends on what you're trying to achieve at a higher level.

For example, let's say you're writing a command line utility that fires background "tasks", then you don't even need to start thread objects explicitly:

#include <iostream>
#include <vector>
#include <future>

int main()
{
    std::vector<std::future<void>> tasks;

    for( char task; std::cin >> task; )
    {
        switch( task )
        {
        case 'q': return 0;
        case 'a': tasks.push_back( std::async( std::launch::async, []{ std::cout << "task a completed.\n"; } ) ); break;
        case 'b': tasks.push_back( std::async( std::launch::async, []{ std::cout << "task b completed.\n"; } ) ); break;
        // ...
        }
    }
}

note: the above may or may not fulfill your requirements; in fact, note that the above will fire a new thread for each task ( this may not be desirable with many concurrent tasks ) and keep trace of every task in the tasks vector, eventually waiting for completion ( or an exception, quietly stored in the future<> object ) at main() exit ( again this may/may not be desirable ) ...

[vincegata]

@OReubens -- about rule number one, why cannot I have a worker thread that is waiting for a user input from console?

[D_Drmmr]

Mandatory reading: http://www.drdobbs.com/parallel/inte...tely/207100682

[OReubens]

@OReubens -- about rule number one, why cannot I have a worker thread that is waiting for a user input from console?

well maybe a slight exageration on my part. technically "you can", but you need to REALLY know what you're doing.
More often than not, trying to do user input (or output to screen) from a thread other than the main thread is a surefire way to get your app to crash, be unstable, or cause all sorts of nasties for the users.

You're using cin for input here though, and then the rules of the library apply:
http://msdn.microsoft.com/en-us/library/c9ceah3b.aspx
reading from cin (considered an object write, since object state changes) is not thread safe.