Re: [boost] Boost.Threads, N2178, N2184, et al

From: Howard Hinnant (hinnant_at_[hidden])
Date: 2007-03-27 15:10:52

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