Boost logo

Boost :

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

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

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! :-\


Boost list run by bdawes at, gregod at, cpdaniel at, john at