Re: Draft of generation 2 thread class

From: bill_kempf (williamkempf_at_[hidden])
Date: 2002-01-24 14:06:58

--- In boost_at_y..., Tom Becker <voidampersand_at_f...> wrote:
> Thu, 24 Jan 2002 14:55:51 -0000, "bill_kempf" <williamkempf_at_h...> 
wrote:
> >--- In boost_at_y..., "davlet_panech" <davlet_panech_at_y...> wrote:
> >  > in addition to check_cancelled(). I think having a way to 
determine
> >>  the cancellation state of a thread with a simple test (as 
opposed
> >to
> >>  an exception) could come in handy in some situations:
> >>
> >  >   while( !cur.is_cancelled() ) {
> >  >     // do somtheing
> >>    }
> >>    // do some other thing
> >>
> >>  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.
> 
> I agree.
> 
> The first example probably won't work as expected. The call to 
> is_cancelled() might actually catch a cancellation if the request 
> comes in after the last cancellation point in "do something". If 
the 
> timing is different, the exception will bypass it, and "do some 
other 
> thing" will never happen. The first example is not equivalent to 
the 
> second.

No, but the "correct" variant of:

disable_cancellations protect;
while( !cur.is_cancelled() ) {
   // do somtheing
}
// do some other thing

should be equivalent, and as Dave points out can allow certain cases 
to be optimized.

Actually, this makes me wonder if the name shouldn't be more along 
the lines of pending_cancellation()?

> The second example violates the "exceptions should be used only in 
> exceptional circumstances" rule. The thread should be written so 
> there's a gentle way to ask it to stop.
> 
>      while (!done()) {
>          // do something
>      }

That seems to be an argument for not including cancellation at all.  
Is that truly what you think?

Bill Kempf