Boost logo

Boost :

From: terekhov (terekhov_at_[hidden])
Date: 2002-01-14 15:50:25

--- In boost_at_y..., "bill_kempf" <williamkempf_at_h...> wrote:
> --- In boost_at_y..., Mac Murrett <mmurrett_at_v...> wrote:
> > On 1/14/02 11:19 AM, "bill_kempf" <williamkempf_at_h...> wrote:
> >
> > > --- In boost_at_y..., Mac Murrett <mmurrett_at_v...> wrote:
> > [snip]
> > >> As an aside, I am in favor of Bill's approach, if we implement
> > > cancellation
> > >> at all. I would suggest making the exception a private member
> type
> > > of
> > >> thread, so that it can only be caught by thread::thread_proxy.
> > >
> > > That won't work.
> > >
> > > try {
> > > boost::mutex::scoped_lock lock(mutex);
> > > }
> > > catch (...) {
> > > // I've caught the exception even though it's a private
> > > // exception type
> > > }
> >
> > I worded that poorly. The point is to document in code that these
> > exceptions are not meant to be caught.
> >
> >
> > > The best that Boost.Threads can do is insure that even if you
> catch
> > > the exception you can't "eat" it. This may still cause
> with
> > > some legacy code, but this isn't a good argument against such a
> > > cancellation mechanism, IMHO.
> >
> > Out of curiosity, how can we do this?
> The solution was posted on here some time ago. The general idea is
> to have the exception's constructor do the re-throw, with a
> for the thread proxy to disable this.

That was destructor (not constructor):

and this might be a problem (wrt memory
deallocation for temporary object or perhaps
something else ;) Now I am just NOT sure that
this short code snipped I've posted a few months
ago here is actually valid C++!

Anyway, that was a WRONG solution! catch(...)/
cancellation/exit is a moot point, I think.
I just rushed in without too much thinking and
should not have done it in the first place because
a) auto_rethrow_exception() just breaks catch(...)
without throw; semantics and b) thread cancel/exit
should NOT be caught without throw; (or
program termination) at all!! Look, you could
always control cancellation (using cancel state
and type) and thread exit exception could carry
not so smart objects (to return to joiner(s))
which could result in resource leaks catching
it without throw; or program termination. Such
code is simply broken! It is just a breach of
contract, I think.


ps. Bill, Peter, mutex locking is NOT a cancelation
point... consider:

"There are several important blocking routines
 that are specifically not made cancelation points:
 — pthread_mutex_lock()
 If pthread_mutex_lock( ) were a cancelation point,
 every routine that called it would also become a
 cancelation point (that is, any routine that touched
 shared state would automatically become a cancelation
 point). For example, malloc(), free( ), and rand()
 would become cancelation points under this scheme.
 Having too many cancelation points makes programming
 very difficult, leading to either much disabling and
 restoring of cancelability or much difficulty in
 trying to arrange for reliable cleanup at every possible
 place. Since pthread_mutex_lock( ) is not a cancelation
 point, threads could result in being blocked uninterruptibly
 for long periods of time if mutexes were used as a general
 synchronization mechanism. As this is normally not acceptable,
 mutexes should only be used to protect resources that are
 held for small fixed lengths of time where not being able
 to be canceled will not be a problem. Resources that need
 to be held exclusively for long periods of time should be
 protected with condition variables."

see POSIX Rationale volume for more details...


Boost list run by bdawes at, gregod at, cpdaniel at, john at