Re: [boost] Ending/canceling/suspending a thread (proposal)

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

> (if you are afraid of some intraprocess resource leakage with
                             ^^^^^^^^^^^^
                             er. interprocess

also, fyi.. posix:

"It was suggested that the cancelation cleanup handlers
 should also be called when the process exits or calls
 the exec function. This was rejected partly due to the
 performance problem caused by having to call the
 cancelation cleanup handlers of every thread before
 the operation could continue. The other reason was that
 the only state expected to be cleaned up by the cancelation
 cleanup handlers would be the intraprocess state. Any
 handlers that are to clean up the interprocess state
 would be registered with atexit()."

regards,
alexnader.

---------------------- Forwarded by Alexander Terekhov/Germany/IBM on
08/23/2001 07:51 PM ---------------------------

Alexander Terekhov
08/23/2001 07:49 PM

To:   boost_at_[hidden]
cc:

From: Alexander Terekhov/Germany/IBM_at_IBMDE
Subject:  Re: [boost] Ending/canceling/suspending a thread (proposal)

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