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