Boost logo

Boost :

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

Boost list run by bdawes at, gregod at, cpdaniel at, john at