4 ms·

Yes except when given a std::thread you don't know whether it will join in the destructor whereas with jthread you do. I personally don't know how it helps. Bu

• masklinn 6y ago
  > I personally don't know how it helps I really don't think it does personally. You can argue one way or the other with respect to safety (and I would very much agree that terminating on drop is insane), but that's really your backstop, and it's not really relevant to the person who is given a thread: they should know what they want to do with it, and if they want to join it they ought do so.
  • dataflow 6y ago
    > it's not really relevant to the person who is given a thread: they should know what they want to do with it, and if they want to join it they ought do so. You might be onto something with this but it's not obvious to me. I would've thought if the caller says "don't join this on destruction", that means "I know what this thread does better than you because I created it, and you cannot expect to be able to wait for it to exit in the general case" (e.g., maybe it infinite-loops or something). Under what scenario would the callee have a good reason to give you a non-auto-joining thread, and you (the caller) a good reason to override that assessment on destruction by default, and why are these scenarios the desired general behavior? (I can understand special cases, like when you pass a particular message to the thread to get it to quit, but not the general case for destructors.)