[cpp-threads] Re: Exception propogation across threads

[Boehm, Hans]

> -----Original Message-----
> From: cpp-threads-bounces at decadentplace.org.uk 
> [mailto:cpp-threads-bounces at decadentplace.org.uk] On Behalf 
> Of Kevlin Henney
> Sent: Wednesday, February 21, 2007 11:14 AM
> To: c++std-ext at accu.org
> Cc: C++ threads standardisation
> Subject: [cpp-threads] Re: Exception propogation across threads
> 
> "Meredith, Alisdair" <Alisdair.Meredith at uk.renaultf1.com> writes
> >
> >At the Portland meeting there were a couple of papers on the idea of 
> >what happens when a thread fails to catch an exception.
> >
> >This seemed a much more open question than originally thought, as it 
> >was not entirely clear what behaviour was expected, although 
> all papers 
> >proposed a mechanism to propagate the exception across a join.
> >
> >Is there yet a consensus view on what the desired behaviour is?
> >
> >i/ terminate whole process, just as when main() fails to catch an 
> >exception ii/ terminate the thread, stack unwinding would be 
> >implementation defined, but otherwise leave process intact 
> iii/ unwind 
> >the stack, and hold exception in abeyance somewhere - 
> rethrow on join 
> >iv/ implementation defined stack unwinding - hold exception 
> in abeyance 
> >somewhere - rethrow on join v/ undefined behaviour vi/ any of the 
> >options I missed ...
> 
> Unwind the stack, terminate the thread and throw some kind of 
> unexpected thread-death exception in the joining thread. Less 
> severe than (i) and (ii), less compiler magic or modification 
> of exceptions needed than
> (iii) and (iv), and more usable than (v).
> 
My recollection from the last discussion is that this has the (probably
fatal?) flaw that the join may not be executed until next month.  Thus
you could effectively be hiding the exception for a month.  Since it
escaped the thread, it was presumably not completely handled, so we are
now letting the application run in a bad state for a month, potentially
wreaking all sorts of havoc.

It seems to me that the best choice is essentialy (i), with enough
facilities to let libraries implement other policies as needed.

Hans