How do worker threads/main thread react when the process is terminated gracefully/forcefully?

[hardy granite]

A.k.a.

why do the docs of std::exit, std::quick_exit, std::_Exit, std::abort, std::terminate NOT say anything about thread safety???

[rugged trench]

When your question is answered use !solved to mark the question as resolved.

Remember to ask specific questions, provide necessary details, and reduce your question to its simplest form. For tips on how to ask a good question use !howto ask.

[distant silo]

if the threads aren't joined, that's not so graceful

[hardy granite]

nope, there's legit detached threads

std::thread(Func1).detach();

My point here is that, these magical std::exit and the others may use some mysterious global variable from glibc unsynchronised, and you get race conditions and crashes instead of, a graceful exit

and the docs say literally nothing

which is insane

[distant silo]

if the detached thread "outlives" the main function, then that's not graceful

[hardy granite]

wrong

so, the real answer may force me to debug glibc

with gdb

and its debug symbols

[distant silo]

std::exit claims to be graceful since, like returning from main, calls destructors and all that jazz

[hardy granite]

that's too ez
what about the others

[distant silo]

wdym wrong

[hardy granite]

detached threads will behave as if, someone sent SIGKILL - they just, stop running

[distant silo]

yes, but that isn't graceful

[hardy granite]

when I say graceful, I mean, you don't get hard crashes or UB at exiting

the worker threads may have pending work, and suddenly they just, die, so not very graceful somewhat

[distant silo]

I mean, calling std::terminate manually doesn't cause any crashes, but it's as ungraceful as it can be

ok maybe std::abort is more ungraceful but you get the point

[hardy granite]

that's kill(getpid(), SIGABRT);

in the implementation of the function abort