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

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

Bill,

Just to underline what I said: I am NOT proposing any specific behavior,
just trying to get the idea that "we have to" out of our heads...

Your design decisions and arguments are as valid as anyone else's in
here, and most of the time much more so, but you do not have The C++
Standard to lean on in these decisions. You (and we) are on your (and
our) own here.

Thanks,

/David

-----Original Message-----
From: boost-bounces_at_[hidden]
[mailto:boost-bounces_at_[hidden]] On Behalf Of William Kempf
Sent: Sunday, August 11, 2002 9:21 PM
To: boost_at_[hidden]
Subject: RE: [boost] Re: Re: Re: Threads & Exceptions

>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

_______________________________________________
Unsubscribe & other changes:
http://lists.boost.org/mailman/listinfo.cgi/boost