Re: first sight

From: terekhov (terekhov_at_[hidden])
Date: 2002-01-14 17:58:58

--- In boost_at_y..., "bill_kempf" <williamkempf_at_h...> wrote:
> --- In boost_at_y..., "terekhov" <terekhov_at_d...> wrote:
> > --- 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):
> 
> Sorry, typo on my part.
> 
> > 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
> 
> What do you mean by this?

I mean that it is my understanding that "catch(...) without
throw;" is only valid if I am 100% sure that ALL exceptions
potentially thrown inside try block could be fully handled 
by my catch(...) code (or I just terminate the process). 
To me, it really does not happen too often, I even do not 
remember the last time I wrote "catch(...) without throw;". 
Do you have some really good example when it is deadly needed? 

> > and b) thread cancel/exit 
> > should NOT be caught without throw; (or 
> > program termination) at all!!
> 
> But that's the problem... current code may have catch(...) with out 
> throw; and thus results in the exception being "eaten".  The idea 
is 
> to prevent this from occuring.

Why not just use pthread_setcancelstate() to disable cancellation 
points?

> 
> > 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.
> 
> Again, I don't understand this.  (I'm sorry, the fault is on my 
end, 
> but I have problems deciphering your english from time to time.)  

*I* am sorry, the fault is on MY end – it is my poor English.

> Why would the "exit exception" carry anything?

Because thread_routines are designed to return something.
pthread_exit (explicitly or implicitly) does it.

regards,
alexander.