Re: [boost] Re: Draft of generation 2 thread class

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2002-01-24 10:27:41

----- Original Message -----
From: "bill_kempf" <williamkempf_at_[hidden]>

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

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.

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

BTW, what happens if a cancellation_disabler outlives its thread? Can we do
better than "undefined behavior"?