Re: first sight

From: bill_kempf (williamkempf_at_[hidden])
Date: 2002-01-14 16:12:56

--- 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?

> 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.

> 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.)  Why 
would the "exit exception" carry anything?

> Such 
> code is simply broken! It is just a breach of 
> contract, I think.

Unfortunately, if we make the cancellation "contract" to restrictive 
there are going to be a lot of breaches from legacy code/libraries, 
which means bugs that are hard to fix, if the coder even has access 
to the source.

So... either cancellation is a very weak request that may unwind only 
part of the stack, or we need to insure a re-throw always occurs.
 
> 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

Interesting point.  Yet more reasons why I don't want to arbitrarily 
add a simple cancellation mechanism.  I'm still learning all of the 
perils of cancellation since my platform doesn't support this 
concept.  I don't think this is a bad decision, after all, a very 
large number of programmers get along quite well with out builtin 
cancellation.  In fact, I often get the impression that the Win32 
programmers are better off with out cancellation, though I do 
understand the desire to include this.

Bill Kempf