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

From: William Kempf (williamkempf_at_[hidden])
Date: 2002-08-11 20:21:20

>From: Darryl Green <green_at_[hidden]>
> > 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.

The problem is that threads are not "async calls" in the way people are 
envisioning.  They can be used that way, but the typical use is not for 
that.  Most threads perform some work, and return values (if present) are a 
side effect.  Take the classic example of the bounded IO monitor.  The 
threads that read and write to this buffer could throw at any point.  
Checking for this at the point of join() won't work because deadlocks are 
likely to occur while the two threads expect IO to continue.  Polling for 
this with other methods won't work, because such a poll would only introduce 
race conditions.  Exception handling in this scenario *must* be addressed on 
a case by case basis... which means explicit coding.  Calling terminate() is 
the surest way I know of to ensure the user either does this explicit 
coding, or the application takes the safest possible course when they don't. 
  Heck, even the argument that a library may spawn threads that throw 
exceptions and the user has no control over them seems to me to favor the 
terminate() approach.  After all, there's not much the application could do 
to recover from such occurances, since it can't restart the errant thread 
even if restarting it could be gauranteed to be the correct resolution here. 
  If you could restart the thread, that means you must have been the one to 
start it, and thus you could wrap it to prevent exceptions from calling 
terminate().

I understand why people think that async calls should throw, but again, 
threads are not async calls in the fashion that people are thinking.

Bill Kempf
williamkempf_at_[hidden]

_________________________________________________________________
Join the world’s largest e-mail service with MSN Hotmail. 
http://www.hotmail.com