Re: first sight

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.