Boost logo

Boost :

From: Alexander Terekhov (terekhov_at_[hidden])
Date: 2001-08-23 12:49:51


> > From: "Scott McCaskill" <scott_at_m...>
> > > You're assuming that use of catch(...) implies that the exception
will
> > > always be re-thrown, but this does not have to be the case and indeed
a
> > > library implementor cannot make that guarantee:
> >
> > No, I don't assume anything like this. Not re-throwing in catch(...)
will
> > ignore the cancelation request. This is a feature.
> >
>
> Ok, I didn't realize that. However I'm uncertain about the value of
> thread::cancel() if it may or may not cause the thread to end. Why would
> one use thread::cancel() unless it does matter whether or not the thread
is
> cancelled?

i agree with Bill; it is a bug (breach of contract) to eat exit
and cancel exceptions. in the case of exit i would even like to
write something like thread::exit( smart_ptr<T>( new T(..) ) );
and have some thread::await_exit routine (plus try/timed
versions) which would unblock waiters (and provide them a raw
ptr to thread function return/exit object - smart_ptr<T> in the
case above) as soon as possible (via broadcast from thread::exit
and not from bootstrap routine) because they are waiting for the
result of my thread function (provided by return or exit or
cancellation) and not for "termination complete" state of my
thread. in the case of cancellation they should better get
"canceled" indication (NULL raw ptr) as soon as possible as
well. the real feature is that you should be able control
thread cancellation state if you really do not want cancellation
(simply disable cancellation).

also, uncaught exception should result in abnormal (by default)
program termination (*required* behavior) just like in it is
already done in the case of single threaded C++ programs, IMHO.
(if you are afraid of some intraprocess resource leakage with
respect to other threads (you really want to unwind their stacks),
just install your own terminate handler which would simply cancel
(and then join) all relevant threads);

regards,
alexander.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk