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
problems
> 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
mechanism
> for the thread proxy to disable this.
That was destructor (not constructor):
http://groups.yahoo.com/group/boost/message/15520
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.
regards,
alexander.
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...
http://www.opengroup.org/austin
regards,
alexander.