I believe what's going on here is that each thread, once it has finished, has a "return" value in its hot little hands.
If you detach the thread, you've said you don't want the "return" value, so as soon as it's finished, the thread can tidy up after itself and leave the building.
Otherwise, until you join (or detach) the thread, it's sitting there, waiting patiently to give its final report, before it tidies up and leaves. (Kind of sad, really, given how much you care !)
| [reply] |
yes, that makes sense. Awwww, now I have thread-guilt!
What doesn't make sense is that if you detach a thread, it gets stomped on when the main thread ends. AFAIK there is no way to say "I don't care what value it returns, but I DO want it to actually get there".
Guess I just want it all ...
| [reply] |
Well, if you want to be sure a thread has finished, in a sense you need to know the final report has been completed -- you're just not going to read it.
The polite thing to do is to wait for the report, collect it, but wait at least until the thread has left your office before tossing the report in the bin.
I look at it this way: when the mother thread terminates the system could wait for all the child threads to finish before knocking the process on the head. But it cannot know that the main thread has terminated cleanly, so the children may be on its hands forever waiting for their dead mother, taking up space, demanding attention, needing to be changed, etc. So the system promptly shoot them -- it's a hard world, with no room for motherless threads.
I suppose mother could somehow promise the system that all the children will leave soon, of their own accord. But, frankly, would you take the word of a delinquent mother ? As if !
| [reply] |
