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

From: William E. Kempf (williamkempf_at_[hidden])
Date: 2002-08-12 10:36:13

----- Original Message -----
From: "Anthony Williams" <anthwil_at_[hidden]>
> 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.

Polling only introduces race conditions, that are likey to result in
deadlock.  Polling is not a robust enough thread safe mechanism for this.

> 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.

Then you're agreeing with terminate() (or similar semantics)?

> 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.

I'm missing the point here.

> 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.

Agreed.  But that doesn't address any of the questions being asked here, or
speak towards an answer.

> 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).

I've agreed with this from the beginning, and is what I suggested others
could do.  I think they'll find severe issues caused by setting a
terminate_handler that simply terminates the thread for all threads (this
technique can work for specific threads quite effectively, but is likely to
cause race conditions and dead lock if applied to all threads).

Bill Kempf