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