From: William Kempf [mailto:williamkempf@hotmail.com]
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