Do not join threads on process exit

[zcbenz]

On Windows the process hangs on exit after running some ops, after some debugging I found that it stuck at the synchronize call in ~StreamThread, which was because the thread was already terminated by OS on process exit.

C++ does not seem to specify when threads are terminated during process exit, but at least on Windows the destructors of static objects are called after the stream threads get terminated, resulting in posting tasks in ~StreamThread not working and thus the hang.

A simple fix is to just let the OS collect the threads, i.e. what this PR does. If you prefer a clean exit, we can have the language bindings destroy the Schedule in their exit handlers, which are called before the actual process exit.

[awni]

but at least on Windows the destructors of static objects are called after the stream threads get terminated

You're saying StreamThread is deleted before Scheduler is deleted. Then in Scheduler destructor it tries to delete the StreamThread which joins on the thread and that causes a bug? What if we check thread.joinable in the destructor of StreamThread? Would it be false?

[zcbenz]

Yeah, the native OS thread got terminated on exit before the std::thread got destroyed. In my tests, once the main() function returns, all threads behaved like they received exit(0), and when using the win32 API to test their liveness, they were reported as exited.

    DWORD code = -1;
    GetExitCodeThread(thread.native_handle(), &code);
    fprintf(stderr, "exit code: %d\n", (int)code);

The thread.joinable() still returns true in this case, I think it is just a soft flag and does not check the actual status of the thread.