[boost] Re: Boost.threads: interthread exceptionconveyance

From: Alexander Terekhov (terekhov_at_[hidden])
Date: 2002-08-26 05:58:08

Darryl Green wrote:
[...]
> > 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."
> >  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> 
> Doesn't this only define what happens before terminate() is called? 

Yes, "strictly speaking", this bit constrains implementations; "only".

> I don't
> see the conflict between this and the use of pthread_exit() (or
> "equivalent") 

Again, ``pthread_exit() (or "equivalent")'' is nothing but an 
exception...

> in a terminate handler in order to get the desired(?) result
> of unwinding then terminating the thread?

Sorry, but here/now I'm going to quote myself: (in reply to
your other message in a "similar" boost thread a couple of
days ago)

http://aspn.activestate.com/ASPN/Mail/Message/1323758
(Re: Attempting resolution of Threads & Exceptions Issue)

<quote>

 Darryl Green wrote:
 [...]
 > > "On Digital UNIX, an unhandled exception in a thread will ... 
 > 
 > On ecos, rtems, amx, psos... there is only 1 "process" - please allow for 
 at
 > least some small chance of success in doing a civilised shutdown over 
 having
 > no chance of doing this. 

<snip>

 David Abrahams wrote:
 [...]
 > If all the code is exception-neutral and gives the basic guarantee, 
 > by the time the thread exits, all program invariants are intact. 
 
 Even if some throw() operation would suddenly throw? Well, if life is
 so perfect as Abrahams seems to paint it, and C++ programs, threads aside,
 are meant to recover whatever-is-thrown at any point, then why does the
 standard have that nice terminate()->abort() mechanism with UNBELIEVABLY
 SHORT list of "situations"/"such cases"... saying *specifically* the
 following [emphasized part], to begin with:
 
 "[except.terminate] The terminate() function
  In the following situations exception handling must be abandoned
  for less subtle error handling techniques: ....
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^(*)

  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.

 (*) < C++ Standard Core Language Active Issues, Revision 22 >

 "Bjarne Stroustrup: I strongly prefer to have the call to
  std::terminate() be conforming. I see std::terminate() as
  a proper way to blow away "the current mess" and get to the
  next level of error handling. I do not want that escape to
  be non-conforming - that would imply that programs relying
  on a error handling based on serious errors being handled
  by terminating a process (which happens to be a C++ program)
  in std::terminate() becomes non-conforming. In many systems,
  there are - and/or should be - error-handling and recovery
  mechanisms beyond what is offered by a single C++ program."

</quote>

regards,
alexander.