Boost logo

Boost :

From: David Bergman (davidb_at_[hidden])
Date: 2002-08-12 11:02:04


Your design is good, probably the only rational one for all possible
thread cases (worker threads, asynchronous calls etc.) I have no problem
with that, although I would rather have a more "embedded" variant, which
would be quite hard to define so that the behavior is consistent in all
the above thread cases.

As an example that there are alternative applications of the C++
Standard onto MT C++: one, fundamentalist, reading of The C++ Standard
gives that each thread should be born with the default behavior for
uncaught exceptions (i.e., unexpected --> terminate --> ending thread).
Thus, the handler vector would need to be reset for the thread. The code
run by the thread should be able to count on that default behavior.
I.e., one should not be allowed to change the unexpected--terminate
behavior before triggering that thread...

So, your design is good, but not the only logical extension of C++ to MT
C++. Another logical extension would be to override "set_XXX_handler" so
that each thread hosts its own handler vector, making them reside in a
C++ compliant environment.


-----Original Message-----
From: boost-bounces_at_[hidden]
[mailto:boost-bounces_at_[hidden]] On Behalf Of William E. Kempf
Sent: Monday, August 12, 2002 11:39 AM
To: boost_at_[hidden]
Subject: Re: [boost] Re: Re: Threads & Exceptions

----- Original Message -----
From: "David Bergman" <davidb_at_[hidden]>
> Bill,
> How can anyone find a killer argument? You have already stated,
> repeatedly, that you are forced to the design of yours because of The
> Standard and the underlying thread libraries... So, there is simply no
> room for a killer argument there.

If that's true, then there should be no desire by anyone to argue the
here. But I'm not going to presume that I'm 100% correct in my
understanding of the issues. The problem is that everyone's been
arguing in
circles instead of tackling the salient points for why I don't think
any other choice to be made here.

> That is what has been a bit irritating to some members here, that you
> not simply state that your decision is (according to you) the best
> overall instead of your decision being the inevitable consequence of
> other necessary factors: The C++ Standard and The Underlying Thread
> Libraries.

I don't get this. If I'm correct, then you have no reason to be
If I'm not, then you should be able to prove me wrong, so there should
be no
reason for irritation there either.

Bill Kempf
Unsubscribe & other changes:

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