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

From: Eric Woodruff (Eric.Woodruff_at_[hidden])
Date: 2002-08-08 10:04:35

In a single threaded environment, there is only one thread to terminate, so
yes, it is obvious. In a multi-threaded environment, none or maybe a select
few of the threads might need to terminate when a thread has an uncaught
exception. Communicating which threads should be terminated is one difficult
task. Another is learning and understanding this completely different
paradigm where the relationship between threads has to be explicit. I'm all
for it though, because almost any non-trivial application uses threads.

Maybe the problem is there are few high-level multi-threading concepts, if
any. Most things are low-level like mutexes and threads. If there was a
better way to describe the synchronicity of a system, the compiler could
even generate the thread_terimate ()s, etc.

----- Original Message -----
From: Darryl Green
Newsgroups: gmane.comp.lib.boost.devel
Sent: Wednesday, 2002:August:07 8:30 PM
Subject: RE: Re: Re: Threads & Exceptions

I'm a little bemused by the way that some parts of a standard which afaik
doesn't consider multi-threading at all, seems to be exerting considerable
influence on what is the "right" way to deal with an uncaught exception in a
thread. I'm thinking specifically here of the "uncaught exception calls
terminate()" behaviour. The logic that leads to this decision appears
obvious in a single threaded environment. The process terminates and if
anything bothers to check/cares the way the process terminated can be
determined (to the extent that the process terminated abnormally, and maybe
more than this if a handler was installed to report something more).
It seems to me (and maybe this is misguided, but I'd really like to know
where I've gone wrong with this) that once one introduces threads each
thread should be considered as though it were an independent process that
just happens to have inherited an awful lot of its parents resources (ie.
all of them) and shares its address space. But what is the per-thread
"terminate()" behaviour? I don't know/it depends/I think it would be
productive to discuss this. I'm not currently buying the "because the
standard says" argument as being terribly valid here, but I'm no expert -
maybe you can explain why this isn't an area where a more "liberal
interpretation" is appropriate. I don't see a huge amount of difference
between one thread be able to check what led to the thread terminating (if
one cares) or ignore it, just as is the case for the process parent when an
process terminates due to an uncaught exception.

Regards
Darryl Green.

> -----Original Message-----
> From: William E. Kempf [mailto:williamkempf_at_[hidden]]
> Sent: Thursday, 8 August 2002 12:35 AM
> To: boost_at_[hidden]
> Subject: Re: [boost] Re: Re: Threads & Exceptions
>
>
> ----- Original Message -----
> From: "Victor A. Wagner, Jr." <vawjr_at_[hidden]>
> To: <boost_at_[hidden]>
> Sent: Wednesday, August 07, 2002 4:39 AM
> Subject: Re: [boost] Re: Re: Threads & Exceptions
>
>
> > At Tuesday 2002/08/06 09:37, you wrote:
> > >From: "William E. Kempf" <williamkempf_at_[hidden]>
> > >[deleted]
> > >terminate() is invoked when there is no matching exception
> handler. If
> > >join() magically transports exceptions across thread
> boundaries, the
> > >exception thrown in main() will be caught by the join()ing
> thread, and
> > >things are fine and dandy.
> > >
> > >Unfortunately, when there is no join(), the uncaught exception must
> > >terminate the process, but we don't know in advance
> whether there will be
> a
> > >join() sometimes in the future!
> >
> > I see an "unreported exception" just like any other resource leak.
> > we don't terminate processes because somebody forgets to do
> a delete[]
> > what's so "magic" about an exception?
>
> The C++ standard explicitly defines the behavior here.  I
> suppose that's the
> "magic" you're referring to.
>
> Bill Kempf
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>
_______________________________________________
Unsubscribe & other changes:
http://lists.boost.org/mailman/listinfo.cgi/boost