[boost] Re: Boost.threads: interthread exceptionconveyance

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:

<quote>

  "William E. Kempf" <williamkempf_at_[hidden]> wrote in message
  news:OE52qXkXriph10Jnoa90000a3bb_at_hotmail.com...
  >
  > 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.

</quote>

<?>

Well, it "can be done" (initial/main thread including, BTW):

http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/EDCLB120/5.1.55
(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 
 process. 
 ...."

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,

     void terminate();

 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."
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

regards,
alexander.