|
Boost : |
From: William E. Kempf (williamkempf_at_[hidden])
Date: 2002-08-13 12:16:53
From: "Anthony Williams" <anthwil_at_[hidden]>
> William E. Kempf writes:
> > I claimed that the concept could not be applied _to the main
> > thread_, because that results in an explicit call to terminate(),
possibly
> > with out stack unwinding, no less.
>
> OK, you've convinced me (with the stack-unwinding (or possible lack
thereof)
> issue) --- unhandled exceptions from any thread should terminate the
process
> by default.
Just to make things as confusing as possible, I'm no longer in the camp of
believing this. The reasons I thought the process should terminate are
still valid, but the fact that the termination handlers would execute in the
context of that thread and how difficult it would be to exit cleanly seem to
weigh much heavier then other factors, so I think only the thread in
question should be terminated.
> If a user wishes to catch/pass through exceptions from a
> thread, then they can install a thread_terminate_handler (of some variety)
to
> do this, under the knowledge that installing such a handler for the main()
> thread (which would have to be done under the guise of a real
> terminate_handler, using set_terminate, even if the library hides this
fact)
> may skip stack unwinding, or cause other problems (depending on the
platform).
set_terminate() applies to the process, not to the main thread. I think
this distinction will cause issues, especially if set_thread_terminate() is
routed to set_terminate() for the main thread in this way. As much as I
dislike the disparity, I think I just have to document that the main thread
behaves differently in this regard.
> (BTW: Are my posts coming through in plain text now?)
Appear to be, yes.
Bill Kempf
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk