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

From: William E. Kempf (williamkempf_at_[hidden])
Date: 2002-08-08 09:44:35

----- Original Message -----
From: "Darryl Green" <green_at_[hidden]>
> I'm a little bemused by the way that some parts of a standard which afaik
> doesn't consider multi-threading at all, seems to be exerting considerable
> influence on what is the "right" way to deal with an uncaught exception in
a
> thread. I'm thinking specifically here of the "uncaught exception calls
> terminate()" behaviour. The logic that leads to this decision appears
> obvious in a single threaded environment. The process terminates and if
> anything bothers to check/cares the way the process terminated can be
> determined (to the extent that the process terminated abnormally, and
maybe
> more than this if a handler was installed to report something more).
> It seems to me (and maybe this is misguided, but I'd really like to know
> where I've gone wrong with this) that once one introduces threads each
> thread should be considered as though it were an independent process that
> just happens to have inherited an awful lot of its parents resources (ie.
> all of them) and shares its address space. But what is the per-thread
> "terminate()" behaviour? I don't know/it depends/I think it would be
> productive to discuss this. I'm not currently buying the "because the
> standard says" argument as being terribly valid here, but I'm no expert -
> maybe you can explain why this isn't an area where a more "liberal
> interpretation" is appropriate. I don't see a huge amount of difference
> between one thread be able to check what led to the thread terminating (if
> one cares) or ignore it, just as is the case for the process parent when
an
> process terminates due to an uncaught exception.

If I were simply writing a proposal for the standard I'd agree with you
100%.  But I'm not.  I'm writing a library that has to obey by todays
standard.  I can't implement thread_terminate() the way it should be with
todays standard, because an exception that's not caught by the main thread
calls terminate().  I'd have two options if I were to try and do this today,
both of which I don't care for:

1) Require MT applications to have a thread_main() entry point and supply
main() within the library.  This would mean the library couldn't be used in
other libraries where you have no control over the actual application code.

2) Have the main thread behave differently in this respect from all other
threads.  This would be workable, but frankly I don't care for it.  I
dislike special case development, especially when, like in this case, little
benefit is provided.  You can change the terminate() behavior in precisely
this way with out any change to the current design simply by providing a
"try { } catch (...) { }" in your threads (which could be done with a
function adapter easily enough).

I agree that a thread_terminate() is appealing and will certainly recommend
it to the committee for consideration.  Along the same lines I find an
at_thread_exit() to be appropriate as well.

Bill Kempf