RE: [boost] Re: Re: Re: Threads & Exceptions

From: Darryl Green (green_at_[hidden])
Date: 2002-08-11 20:01:16

> From: William Kempf [mailto:williamkempf_at_[hidden]]
snip...
> Sorry, I refuse to supplant main() in Boost.Threads.

I'm with you on that one at least.

> From: William E. Kempf [mailto:williamkempf_at_[hidden]]
> But I don't think that simply calling
> terminate() results in the problems you think it does.  By setting a
> terminate() handler and checking what thread has called it, you can stop
the
> termination (and more importantly, set up some sort of error handling
> here!).

Sorry my message was a bit rushed (and long enough already, I deleted some
stuff about terminate handlers from it). I realise you can change what
terminate does - I do it. It seems to come down to the reasons why you don't
(want to)? A threading lib that makes various forms of "async execution"
easy/natural in C++ is bound to lead to cases where catching (relatively
easy) and dealing with (not very easy at all in this sort of model)
exceptions within the thread that caused them is not desirable. Im talking
here from the users perspective - obviously the impl. does need to catch and
process the exception somehow to produce the desired effect. It is extremely
desirable that whatever the mechanism is for doing this it is consistent -
having each library that uses async execution do its own thing to
propogate/report exceptions is not going to work. Doesn't this make
including it at a very low level in the threading libraries essential? If
that means leaving it "broken" for some usage pending language support (I
suspect that this is doable at the lib level so long as you think crt0 etc
are libs...) so be it. I'm still not convinced that we can deduce what is
required C++ standard behaviour in a multithreaded app - but I'm prepared to
defer to those with more expertise on that one.