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