Boost logo

Boost :

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


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.



-----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
> > termination (and more importantly, set up some sort of error
> > here!).
>Sorry my message was a bit rushed (and long enough already, I deleted
>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
>(want to)? A threading lib that makes various forms of "async
>easy/natural in C++ is bound to lead to cases where catching
>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
>here from the users perspective - obviously the impl. does need to
>process the exception somehow to produce the desired effect. It is
>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?
>that means leaving it "broken" for some usage pending language support
>suspect that this is doable at the lib level so long as you think crt0
>are libs...) so be it. I'm still not convinced that we can deduce what
>required C++ standard behaviour in a multithreaded app - but I'm
>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
likely to occur while the two threads expect IO to continue. Polling
this with other methods won't work, because such a poll would only
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
  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
terminate() approach. After all, there's not much the application could
to recover from such occurances, since it can't restart the errant
even if restarting it could be gauranteed to be the correct resolution
  If you could restart the thread, that means you must have been the one
start it, and thus you could wrap it to prevent exceptions from calling

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

Join the world's largest e-mail service with MSN Hotmail.

Unsubscribe & other changes:

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