From: Alexander Terekhov (terekhov_at_[hidden])
Date: 2002-08-24 16:57:43
"Victor A. Wagner, Jr." wrote:
> At Saturday 2002/08/24 10:46, you wrote:
> >I hope this rerun of The Meta Thread is better than the original...
> >My interpretation of the latest comments by Bill (= Bill Kempf) was that
> >uncaught exceptions should cause a termination, but not of the process,
> >but instead of the thread, using some "terminate_thread". There would
> >still be no attempt to duplicate that exception for catching in other
> >threads (joiners or not). After that comment, the "tumult" ceased, and
> >the first iteration of the frensic thread was ended. That I regarded as
> >a silent consensus (which was probably totally wrong...).
> I think it ended when I offered to help, and Bill provided a set of
> "requirements" (damifino where he got them) to go into the code. I figured
> I wait until he'd finished all the changes we was going to put into the
> release before I started mucking with it. Unfortunately, the release has
> been pushed back (and i've been busy anyhow). ....
Do you mean:
"William E. Kempf" <williamkempf_at_[hidden]> wrote in message
> This means terminate_thread()
> instead, which only terminates the current thread and not the application.
> A set_terminate_thread_handler() can be employed to handle this case in the
> same manner that you'd use for application termination.
Well, it "can be done" (initial/main thread including, BTW):
(5.1.55 set_terminate() -- Register a Function for terminate())
Note that the function registered for terminate() must terminate
execution of the program without returning to its caller(). If
set_terminate() has not yet been called, then terminate() calls
a system-defined default terminate handler, which calls abort().
In a multithreaded environment, the terminate function created
by the issuance of a set_terminate() call applies to all threads
in the (POSIX) process. If a thread throws an exception which is
not caught by that thread of execution, then terminate() is called.
The default terminate() action calls abort() which by default cause
a SIGABRT signal. If there is no signal handler, then SIGABRT
terminates the process. You can override this with a thread-level
termination by suppling a function which invokes pthread_exit()
as a terminate function. This terminates the thread but not the
But it doesn't really make any sense, IMO. For example, consider:
ISO/IEC 14882:1998(E), Pg. 298 (note 134)
"For example, if the object being thrown is of a class with
a copy constructor, terminate() will be called if that copy
constructor exits with an exception during a throw."
Well, this stuff aside, consider that pthread_exit() is nothing
but a) store the argument in the thread object for POSIX joinable
thread and b) throw "thread_exit" exception to unwind the stack;
call POSIX/C thread cleanup handlers, etc.
But "stack unwinding" (to the extent that there can be >>NO<<
try scope at all; see the definition of "stack unwinding" term)
explicitly PROHIBITED in all but one terminate() cases:
ISO/IEC 14882:1998(E), Pg. 299
"In such cases,
is called (18.6.3). 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."
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk