RE: [boost] Re: Boost.threads: interthread exceptionconveyance

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

Alex,

You are incredible at finding those tiny little clauses that some of us
(at least I) just browse through. A lot of "do it yourself" is to be
found in the standard documentations, yes.

Thanks,

David

-----Original Message-----
From: boost-bounces_at_[hidden]
[mailto:boost-bounces_at_[hidden]] On Behalf Of Alexander Terekhov
Sent: Saturday, August 24, 2002 5:58 PM
To: boost_at_[hidden]
Subject: [boost] Re: Boost.threads: interthread exceptionconveyance

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

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