On Mar 27, 2007, at 2:50 PM, Peter Dimov wrote:
Howard Hinnant wrote:
I'm beginning to think:
multijoin() const { // Don't want to pretend to join with non-existent // (or detached) thread, make noise if (handle_ == 0) throw ?; while (!tl->done) tl->cv1.wait(); }
join() { multijoin(); detach(); }
I think it should be more like:
multijoin() const // try, timed same { if( handle_ != 0 ) // the NULL thread is considered terminated while (!tl->done) tl->cv1.wait(); }
Doesn't this have the detach()/multijoin() bug I demonstrated earlier? (demonstrated with join() earlier) Oh, assuming detach has pthread_detach semantics.
join() { if( handle_ == 0 ) assert, throw acc. to taste multijoin(); detach(); *this = std::thread(); }
I still think that the user would be free to build destructive join/ detach upon the provided interface and that we don't really have to provide them.
I agree that join() would be syntax sugar for multijoin();detach(); but in this case I think it is worth it. I can imagine clients often wanting to bind(_1, &thread::join) and it would be inconvenient to have to keep building that functional out of multijoin and detach. If we need to get rid of one of join() or multijoin(), I'm strongly voting for giving multijoin() the boot. If for no other reason than join() has the proven track record of pthread_join semantics. -Howard