Re: Draft of generation 2 thread class

From: bill_kempf (williamkempf_at_[hidden])
Date: 2002-01-24 10:44:10

--- In boost_at_y..., "David Abrahams" <david.abrahams_at_r...> wrote:
> 
> ----- Original Message -----
> From: "bill_kempf" <williamkempf_at_h...>
> 
> 
> > > as opposed to
> > >
> > >   try {
> > >     while( true ) {
> > >       // do something
> > >     }
> > >   catch( thread_cancel & ) {
> > >     // do some other thing
> > >   }
> >
> > I'd like to hear some other people's opinion on this one.  My 
first
> > reaction is that this won't really serve any useful purpose and 
can
> > actually lead to poor coding practices, but I've formed bad 
opinions
> > in this area before.  So, I'd like to hear other people's 
thoughts.
> 
> 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.

> 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.  Maybe there is utility in some cases where 
the check will always occur in the entry function, but... when would 
the speed of terminating the thread ever be a practical concern?
 
> 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.
 
> 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.

Bill Kempf