Re: Draft of generation 2 thread class

From: bill_kempf (williamkempf_at_[hidden])
Date: 2002-01-24 11:15:20

--- In boost_at_y..., "David Abrahams" <david.abrahams_at_r...> wrote:
> 
> ----- Original Message -----
> From: "bill_kempf" <williamkempf_at_h...>
> 
> 
> > > Anything can lead to poor programming practices. It's one thing 
to
> > call a
> > > state-changing interface dangerous, but informational 
interfaces?
> > When you
> > > need the info and the library doesn't provide it, you're really 
up
> > a creek
> > > with no paddle.
> >
> > I agree totally, but if an interface gives no practical 
usefullness
> > but can still lead to poor practices should you still consider
> > including it?  What purpose would it serve to check the 
cancellation
> > state? Alexander Terekhov appears to have the same reservations 
that
> > I do based on existing practice in Java.
> 
> This sounds suspiciously like legislating morality.

It wasn't meant to be.

> > > It's not as though the thread's cancellation state is a private
> > > implementation detail; you can always find out by asking it to
> > throw an
> > > exception. Throwing can cost, though, sometimes a lot. On some
> > platforms a
> > > really lightweight thread might want to permanently disable
> > cancellation and
> > > do the checking manually, then exit at the appropriate time.
> >
> > The "exit at the appropriate time" is the tricky thing. Unless 
this
> > occurs in the entry function there's no way to "exit" with out
> > throwing an exception.
> 
> Sure there is. There are other ways to unwind. Some people use 
error return
> codes. As much as I believe in the power of EH, I guess I agree 
with a
> previous poster who is concerned about people who have EH turned 
off.
> Embedded applications sometimes need to do this (sometimes for 
technical
> reasons, sometimes for political reasons). It should be possible to 
write
> portable threading code without throwing an exception.

OK, I'm convinced enough to add this.
 
> > > I guess that means that there should be some way to permanently
> > disable
> > > cancellation. The best I can do is:
> > >
> > > void thread_main()
> > > {
> > >     new disable_cancellation; // leaked
> > >     ...
> > > }
> >
> > void thread_main()
> > {
> >    disable_cancellations protect; // no leak
> >    // the rest of the operation
> > }
> >
> > That is precisely what I had envisioned, as there are many cases 
in
> > which a thread needs to permenantly have cancellation disabled.
> 
> The problem here is that if a cancellation request is posted, it 
throws just
> before exiting :(. Oh, no it doesn't, what am I thinking? OK.

*chuckles*  I though you were missing something here but didn't know 
how to point it out.  There's a reason the constructor and destructor 
for disable_cancellations are not "cancellation points".
 
> > > BTW, what happens if a cancellation_disabler outlives its 
thread?
> > Can we do
> > > better than "undefined behavior"?
> >
> > Not with out making these objects truly thread sharable, which is 
a
> > bad idea for many reasons.  I also see no reason why these should
> > ever outlive the thread, and expect that heap allocations are 
going
> > to be an EXTREMELY rare thing.  They are meant to be scope 
objects.
> 
> OK, you're right.

I am occasionally, at least :).

Bill Kempf