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

From: Darryl Green (green_at_[hidden])
Date: 2002-08-08 22:09:58

> -----Original Message-----
> From: William E. Kempf [mailto:williamkempf_at_[hidden]]
snip...
>  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).
> 

Surely we don't really need a main "wrapper" as per option 1 and can assume
that main, of all functions, is the one that can definitely be modified and
isn't part of some library. The pragmatic programmer (r), who is used to
apparently arbitrary special cases far more ugly than this one simply
writes/uses the following if the special behaviour of main needs to be
overridden. This is much easier to do than modifying every other thread
(especially if we don't "own" them). If this isn't done, the default,
defined, behaviour of main prevails and we assume that is what the
programmer wanted?

main () {
try {
  everything that was in main...
} catch (...) {
  thread_terminate();
}
}