you can think of the process as running a script of your own. If your script fails, no matter what child process or thread you open, it all disappears. If you think it exited normally, but you can actually see it in ps, your process or thread has not been cleaned up, so that your main program is still alive.
on Windows < foreground thread terminates, the program ends and the background thread is terminated. The
process waits for all the foreground threads to finish its work , but if there are only background threads left, it ends the work directly.
Let's start with multithreading: the thread is dependent on the process, and if the process ends, all threads in the process will end. It can be understood that each process will have at least one thread: the main thread. The threads created by the main thread depend on the process. That is, it is impossible for a thread to run independently from the process.
Let's talk about the case of multi-process: in the Unix/Linux environment, there are three situations:
- before the main process ends, it waits for the end of its child process through the wait system call, and reclaims its resources at the same time.
- if the main process does not do so, but ends regardless of itself, then its children will become orphan processes and will be taken over by process 0 (init). Init is responsible for reclaiming the resources of the child process.
- if the main process is a daemon (running indefinitely), but it is not wait its own child process, then after each child process ends, it will leave a little resource release (an entry in the process entry table) that cannot be released, thus forming a "zombie process". Over time, there is a risk of running out of system resources. Therefore, we should try our best to avoid this kind of situation.
the windows environment should be similar, but there is little research.
