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

From: David Bergman (davidb_at_[hidden])
Date: 2002-08-09 11:30:41

Bill,

You are totally right in that in order to comply with the C++ standard,
any uncaught exceptions need to implicitly invoke the registered
"unexpected_handler" for the "program", and the default implementation
of that handler would then invoke the registered "terminate_handler".

The "only" problem is what is meant by "program". A plausible mapping of
the C++ mono-threaded standard would be to project "program" onto
"thread", in which case one would need thread-specific
"unexpected_handler" and "terminate_handler" registries.

Another projection, which is the one you propose, is onto "OS process".

I am quite confident that the C++ standard means that the *current
(implicit) thread of execution* should be terminated when an uncaught
exception is thrown (with the default handlers, at least). If you have
further information underlining your projection, so that The Standard
really meant for the complete OS process to end (by default) as soon as
an uncaught exception occurs in any thread, I give in, at least with
regards to "standard compliance"; although I would still argue that it
still is quite irrational (but that is just my Extremely HO).

My projection of "program" would require the thread layer to catch any
exception and use the thread-specific "unexpected_handler". That would
in fact require the handler registry to be extended so that each entry
essentially is a map from thread Ids to a real handlers. One way to
accomplish this is to override the default handlers (with set_terminate
and set_unexpected) and making those default handlers bifurcate into the
thread-specific handlers, thereby having the resulting handler
registries work as the C++ standard states, but with one handler vector
per thread.

The standard aside, do you consider it to be logical that an uncaught
exception in a progress updating thread in our 40-thread (SuperServer)
program would cause the whole program to cease? And, do you consider
that to be coherent with what the standard states? This is where we
disagree.

We have the luxury to choose the projection of "program" here, so let's
do it in a sound manner.

/David

-----Original Message-----
From: boost-bounces_at_[hidden]
[mailto:boost-bounces_at_[hidden]] On Behalf Of William E. Kempf
Sent: Friday, August 09, 2002 9:45 AM
To: boost_at_[hidden]
Subject: Re: [boost] Re: Re: Re: Threads & Exceptions

----- Original Message -----
From: "David Bergman" <davidb_at_[hidden]>

> I totally agree that the procedural semantics should resemble that of
> the C++ standard as much as possible, but the freedom of
interpretation
> (i.e., the variety of possible mappings of the mono-threaded semantics
> to the multi-threaded "reality") should be acknowledged. Thus, the
> question whether something "complies" should be open for (a creative)
> discussion.

Again, the problem is that the underlying thread APIs don't specify what
happens in this case, while the C++ standard clearly does.  So the
choice is
to obey the standard, or invoke what's not only undefined by the
standard,
but also by the threading APIs.

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