3 ms·

> The main reason is so that the type system knows which thread is which and can handle it differently. Why is this useful in this case, is my question. You ca

> The main reason is so that the type system knows which thread is which and can handle it differently. Why is this useful in this case, is my question. You can try to put lots of things into the type system that aren't, but that doesn't automatically make them better. In fact I'd argue it makes things worse here, e.g., now every container will be instantiated twice depending on whether you use jthreads or threads, almost doubling the amount of work the compiler has to do for them.

throwaway912598 6y ago
It's useful because you may be able to make compile-time decisions on the basis of the type of thread you're dealing with. What those are, I don't know. As for instantiations, an astute library developer will be able to do the right thing. It's not that hard.
gpderetta 6y ago
say you have function that returns a thread object (which is perfectly fine as std::thread is moveable). The caller cannot assume that the thread will join on destruction and needs to conservatively join or detach explicitly anyway. Re container, they will only be instantiated twice if you actually use both std::jthread and std::thread of course. The idea (which I disagree) is that jthread is the better solution and std::thread is sort of deprecated.
- dataflow 6y ago
  > The caller cannot assume that the thread will join on destruction and needs to conservatively join or detach explicitly anyway. This seems a little backwards to me? If the thread should join on destruction then that flag should be set. If not then it should be clear. I'd argue that flag should probably be set in general (and it seems you might feel the same way), but if you have a reason to clear it, then you're just fighting your own program by ignoring it. > Re container, they will only be instantiated twice if you actually use both std::jthread and std::thread of course. The idea (which I disagree) is that jthread is the better solution and std::thread is sort of deprecated. Good point!
  - gpderetta 6y ago
    the function that will be affected by the thread blocking might not be the one that has created the thread so it might not have a chance to set the flag. Of course you can handle it by declaring and documenting preconditions and so on, but, when possible, enforcing these sort of things at the type level is better.

throwaway912598 6y ago

It's useful because you may be able to make compile-time decisions on the basis of the type of thread you're dealing with. What those are, I don't know. As for instantiations, an astute library developer will be able to do the right thing. It's not that hard.

gpderetta 6y ago

say you have function that returns a thread object (which is perfectly fine as std::thread is moveable). The caller cannot assume that the thread will join on destruction and needs to conservatively join or detach explicitly anyway. Re container, they will only be instantiated twice if you actually use both std::jthread and std::thread of course. The idea (which I disagree) is that jthread is the better solution and std::thread is sort of deprecated.

dataflow 6y ago
> The caller cannot assume that the thread will join on destruction and needs to conservatively join or detach explicitly anyway. This seems a little backwards to me? If the thread should join on destruction then that flag should be set. If not then it should be clear. I'd argue that flag should probably be set in general (and it seems you might feel the same way), but if you have a reason to clear it, then you're just fighting your own program by ignoring it. > Re container, they will only be instantiated twice if you actually use both std::jthread and std::thread of course. The idea (which I disagree) is that jthread is the better solution and std::thread is sort of deprecated. Good point!
- gpderetta 6y ago
  the function that will be affected by the thread blocking might not be the one that has created the thread so it might not have a chance to set the flag. Of course you can handle it by declaring and documenting preconditions and so on, but, when possible, enforcing these sort of things at the type level is better.