[boost] Re: Boost.threads: interthread exception conveyance

From: Alexander Terekhov (terekhov_at_[hidden])
Date: 2002-08-24 10:53:02

Dan'l Miller wrote:
[...]
> I never saw a clear & concise conclusion stating "Boost.threads shall 
> do this" ....

FWIW, my "conclusion" is this:

http://groups.google.com/groups?threadm=3D613D44.9B67916%40web.de
(Subject: Re: High level thread design question)

"....
 new_thread{< thread >}( function{, ...args...} );

 {exception_propagator< exception{, ...exceptions...} >::}
   {thread_attr_object.}new_thread( function{, args} );

 {exception_propagator< thread, exception{, ...exceptions...} >::}
    {thread_attr_object.}new_thread( function{, args} );

 For example, given:

   void operation(); // Oh, BTW, in the next release this might throw std::bad_alloc

 We could then have:

   a) no propagation of exceptions on join ["default"]:

        new_thread( operation );

        new_thread< my_fancy_thread >( operation );

        thread::attr().set_name( "007" ).
          new_thread( operation );

        my_fancy_thread::attr().set_something( something ).
          new_thread( operation );

   b) propagation of exceptions [specified at thread CREATION point] on join:

        exception_propagator< std::bad_alloc >::
          new_thread( operation );

        exception_propagator< my_fancy_thread,std::bad_alloc >::
          new_thread( operation );

        exception_propagator< std::bad_alloc >::
          attr().set_name( "007" ).
            new_thread( operation );

        exception_propagator< my_fancy_thread,std::bad_alloc >::
          attr().set_something( something ).
            new_thread( operation );
 ...."

Never joined threads could then provide "unexpected handler" that 
would be invoked automatically either on thread termination (with 
no other refs hanging around) or when the last reference ceases 
to exist; that would be in the context of another thread, then. 
It (i.e. "unexpected handler" for exceptions meant to be caught,
stored and "propagated" on join -- raised in ANY "joined" thread) 
may even throw something like "eat_ignore_me_and_continue" to 
prevent process termination (terminate()->abort()) -- the default.

regards,
alexander.