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