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

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2002-01-24 11:04:58

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

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

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

Quite possibly. It's best not to presume.

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

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