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

From: David Bergman (davidb_at_[hidden])
Date: 2002-08-09 16:09:55

Eric,

Another point is that I was talking about two related but distinct
issues:

1. Have separate handler vectors for the individual threads
2. Catching uncaught exceptions in a thread wrapper

You are right in that we want to unwind the stack, which would require
at least (2) and probably (1). The (1) could be useful in conjunction
with (2) when the "3rd party" library function sets the handlers by
set_unexpected and set_terminated. (1) is obviously a quite hairy piece
to get right...

/David

-----Original Message-----
From: boost-bounces_at_[hidden]
[mailto:boost-bounces_at_[hidden]] On Behalf Of Eric Woodruff
Sent: Friday, August 09, 2002 1:12 PM
To: boost_at_[hidden]
Subject: [boost] Re: Re: Re: Re: Threads & Exceptions

I don't understand. If an uncaught exception is propagated all the way
out
of main, what is the emphasis on "should be" in "should be terminated
when
an uncaught exception is thrown"? It (main) has terminated once an
exception
is thrown that far, and since the standard follows one of the most
illogical
naming schemes, it calls terminate () instead of terminated (). Here the
naming error is that terminate () is an observation, not a command
(passive
vs active)--as far as I know.

In the example:

int main () {
    throw "no handler for me :(";
    return 0;
}

If terminate () does nothing, the program will still exit, but in a
seemingly error-free fashion, correct?

"In the situation where no matching handler is found, it is
implementation-defined
whether or not the stack is unwound before terminate() is called. In all
other situations, the stack shall

not be unwound before terminate() is called."

Hrm, what is the state of the stack for the end-user's perspective? It
seems
like main () would have to have already unwound no matter what. So the
statement in the standard only dictates what happens behind the scenes,
in
the language implementation?

On another note: One could easily write a thread specific unexpected
handler
for the thread that is even just another user boost::function which
would be
called in the event of an unlisted exception as long as the thread wraps
the
execution of the user boost::function (as in my code example).

----- Original Message -----
From: David Bergman
Newsgroups: gmane.comp.lib.boost.devel
Sent: Friday, 2002:August:09 12:30 PM
Subject: RE: Re: Re: Re: Threads & Exceptions

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

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

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