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

From: Howard Hinnant (hinnant_at_[hidden])
Date: 2007-03-25 20:18:06

On Mar 25, 2007, at 7:54 PM, Peter Dimov wrote:

> Howard Hinnant wrote:
>
>> What has me worried about adding try/timed_join to N2184 is actually
>> N2178! :-)
>
> :-)
>
> But that is why N2178 also has pthread_*join2_np. The amount of work  
> that is
> required from a pthread implementation to make pthread_cancel C++  
> friendly
> is much more than what's needed to provide the extensions.
>
>> The other, extremely remote, possibility is to ask the posix group to
>> add pthread_try_join and pthread_timed_join.  They might even be
>> willing to do this.  However there is just no way we're going to get
>> that committee to mandate that pthread_cancel emits a catchable C++
>> exception.
>
> I just got permission to quote Hans Boehm here, since he put it much  
> better
> than I could in a post to POSIX-C++:
>
> "To me, this reaction makes perfect sense in many contexts, but I'm  
> not
> sure it makes sense here.  I do not work with the people at HP who  
> would
> have to fix this.  But what I've heard in the past is that there is
> enough dissatisfaction with the fact that cancellation & C++ basically
> doesn't work that most people would like to see this fixed.  The  
> hassle
> involved in doing the work is probably less than that of listening to
> the continuous complaints.
>
> My impression is that this is probably one of the more superficial
> problems with C++ & pthreads, but it seems to be the one that draws  
> the
> most complaints.  And implementers would like guidance as to the  
> correct
> solution."
>
> It seems very likely to me that once threads are officially  
> recognized by
> the C++ standard, the customers will demand unified C/C++  
> cancelation, and
> do that loudly. So regardless of what the POSIX committee says,
> pthread_cancel will start throwing something that looks like an  
> exception to
> C++ code, earlier or later. We should be prepared for that.

<grin>  Yeah, glad you're listening to POSIX-C++.  Hans speaks quite  
elegantly.

I definitely would like to allow pthread_cancel to throw an  
exception.  I suspect this will even become the norm on 64 bit  
platforms.  But I'm still very worried about 32 bit platforms and I  
don't think it will be the norm there.  There's so many backwards  
compatibility problems.

I agree with you that there are good use cases for try/timed_join.   
And for the 32 bit systems I'm worried about, they can be added no  
cost to the N2184 model.  For the 64 bit systems, your pthread  
extension functions look like a good route to pursue for keeping these  
zero-cost.

Note that simply allowing pthread_cancel to throw an exception doesn't  
make C and C++ cancellation portably interoperable.  So we've still  
got a problem there.  Indeed maybe even a bigger one:  fclose is  
allowed to throw! :-\

-Howard