Re: first sight

From: bill_kempf (williamkempf_at_[hidden])
Date: 2002-01-16 10:09:28

--- In boost_at_y..., Lee Brown <lee_at_a...> wrote:
> On Tuesday 15 January 2002 10:24, you wrote:
> > --- In boost_at_y..., Lee Brown <lee_at_a...> wrote:
> > > O
> > >
> > > > > FWIW here's an old proposal of mine:
> > > > >
> > > > > http://groups.yahoo.com/group/boost/message/16471
> > >
> > > <excerpt>
> > > A thread can terminate itself by throwing
> > > an exception of type "thread_end" or a type derived from 
thread_end.
> > > </excerpt>
> > >
> > > Or it can just terminate and release all resources that it has a
> >
> > hold of.
> >
> > Which fails to call destructors, which is simply not acceptable.
> >
> > Bill Kempf
> 
> Why is this so unacceptable?  Whenever a resource is allocated, in
>  a constructor or whatever.  
> 
> Where is the flaw in the following?  I must be missing something 
here.
> 
> class Lock {
>  Lock(mutex& m) : m_(m) {
>           disable_cancel();
>           m_.lock();
>           push_cleanup(m_ , &muxtex::unlock)
>           enable_cancel();
>  }
> 
>  ~Lock() { 
> 	disable_cancel();
> 	pop_cleanup(); 
> 	enable_cancel();
>    }

It's not acceptable because ALL destructors must be run in order to 
insure ALL resources are properly reclaimed.  You are attempting to 
work around this above by using the C concept of a cleanup stack.  
This works fine in C because C doesn't have destructors and stack 
unwinding isn't expected.  How many conforming programs today, 
however, would crash and burn in a MT system that relied on cleanup 
stacks instead of actual stack unwinding and destructors?

C++ has a mechanism for cleaning up resources, and trying to blend it 
with a C concept for the same thing is just going to lead to trouble.

> BTW: I was able to get  a templated version of thread.start to work.
> Did you avoid this for any reason?

There's no reason for it.  A boost::thread::start() provides no added 
benefit, and in fact only complicates the implementation and the user 
code.
 
Bill Kempf