Re: first sight

From: bill_kempf (williamkempf_at_[hidden])
Date: 2002-01-15 10:18:34

--- In boost_at_y..., "terekhov" <terekhov_at_d...> wrote:
> --- 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:
> > > 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? 

No, but programmers frequently do things that aren't "deadly 
needed" ;).  As I've said before, in library code I'd consider this a 
bug... but if it does occur (and I'm sure it does) the strict rules 
in a cancellation design that allows a catch(...) without a throw; is 
just going to make life miserable for our users.

Worse yet, if you allow catch(...) with out a throw; some user *IS* 
going to make use of this no matter what you document.  Why allow 
them to abuse the system when you can prevent it (assuming we can)?
 
> > > 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?

Well, first, we're using Boost.Threads not pthreads ;).

Seriously, though, the goal isn't to disable cancellation.  We may 
*NEED* cancellation in this fictitious application where some library 
code isn't "playing nice".  There's just no solution to the problem 
other than reporting it as a bug to the vendor (who may not agree and 
refuse to do anything) and wait for them to correct it.  Terribly 
frustrating, and if we can prevent this from happening we should try.
 
> > > 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.

You usually do a fine job.  And others can usually figure out what 
you're saying.  So, let's both accept some responsibility here :).
 
> > Why would the "exit exception" carry anything?
> 
> Because thread_routines are designed to return something.
> pthread_exit (explicitly or implicitly) does it.

A) You're thinking too much about POSIX.
B) Boost.Threads will use it's own cancellation mechanism (it must, 
because the POSIX mechanism isn't gauranteed to play nice with C++, 
and in fact does not on many platforms, and fixing it is not 
something we can do portably).
C) Boost.Threads doesn't (directly) return a value.

I see no need to carry any state with the cancellation exception.

Bill Kempf