RE: [boost] Re: Re: Threads & Exceptions

From: Anthony Williams (anthwil_at_[hidden])
Date: 2002-08-12 09:26:22

From: William Kempf [mailto:williamkempf_at_[hidden]]
Sent: 12 August 2002 13:54
> >If join is called on a thread that terminated through an 
> exception, then 
> >you
> >could notify the caller of join that the thread terminated through an
> >uncaught exception, but that is another issue.
> 
> And how do other threads know that the thread has terminated? 
>  And remember 
> the mechanism needs to be thread safe.  And even after that, 
> what should I 
> do with the knowledge if the thread in question is one 
> created by some 
> library?

Suppose you create a set of threads. If you care about the status of those
threads, then you either join() them, or you can poll them to check they are
still running. If a thread terminates (by any means) then these mechanisms
pick up on that fact, and could possibly transfer info about _how_ the
thread terminated.

If you don't care, you just leave them be. If they die, they die.

Of course, you could add a thread_terminate_handler that calls abort() for
the unhandled-exception case.

If a 3rd party lib creates threads without using Boost.Threads, then you
cannot reasonably have any expectation over how those threads will interact
with those started using Boost.Threads, other than the fact that they are
using the same underlying OS thread support --- they might have the
equivalent of catch(...) in all their thread functions, or they may not;
they might call functions written in other languages, which can't cope with
C++ exceptions at all.

OTOH, if a 3rd party library does use Boost.Threads, then we can expect that
the developers are aware of how Boost.Threads works, and comply with any
decisions made --- if Boost.Threads abort()s on unhandled exceptions, then
the 3rd party lib needs to add catch(...) blocks if they want different
behaviour; if Boost.Threads just kills the thread on unhandled exceptions,
then the 3rd party lib needs to cope with that; if Boost.Threads has
configurable behaviour, then the 3rd party lib needs to cope with that.

As I said before, the fact that main() calls terminate() in response to an
unhandled exception doesn't have to mean that all unhandled exceptions in
all threads must result in a call to abort() --- you can install a
terminate_handler to do what you like, provided it terminates the current
thread in some fashion (it can't return), in which case you can ensure that
all threads (including main() ) have consistent behaviour; you can then
supply a thread_terminate_handler to implement whatever semantics are chosen
(even if it _is_ to call abort() by default), and the user can override it
to (for example) call thread_exit (or vice-versa).

Anthony