Boost logo

Boost :

From: bill_kempf (williamkempf_at_[hidden])
Date: 2002-01-14 10:27:57

--- In boost_at_y..., Lee Brown <lee_at_a...> wrote:
> On Sunday 13 January 2002 10:33, you wrote:
> > On Sun, 13 Jan 2002 11:19:41 +0100, Jens Maurer
<Jens.Maurer_at_g...> wrote:
> > >Lee Brown wrote:
> > >> I do have one question: why doesn't Boost.threads seem to
> > >> thread cancelation? It doesn't seem to be mentioned in the
> > >> documentation.
> > >
> > >Thread cancelation is difficult to do correctly in a C++ program,
> > >because you want to run all the destructors of stack objects of
> > >the thread being canceled.
> Yes, this is true.
> Maybe Im an idealist but I think C++ should be able to do
everything C
> can do but usually better and with more typesafety and more
stability. This
> includes immediate thread cancelation. Lets face it,
> capabilities are
> a fundamental element of programming especially for general purpose
> like C++. Multithreading is supposed to be a primary selling point
> C++ is frequently used for servers which dispatch many tasks
> IMO, "we can't do that" is not an acceptable answer.

I'm not sure I agree. When C allows you to do something that's
dangerous or even fatal in C++ you should really consider long and
hard before allowing it in C++. If cancellation were to work in C++
as it does in C then the stack would not be properly unwound. If you
unwind the stack this is an exception mechanism (even if traditional
C++ exceptions aren't used) and all of the dangers that had to be
addressed with exceptions exist here as well. So asynchronously
cancelling a thread while it's unwinding the stack from another
exception is a very bad idea.

I'm not completely claiming that asynchronous cancellation shouldn't
exist in C++, but if they do they should have some compiler support
to insure some very strict rules are followed about when asynchronous
exceptions can be enabled by a thread. Boot.Threads won't have such
compiler support, so don't expect me to include asynchronous

> > Throwing an exception will do the clean up.
> Ideally, IMO, thread cancelation is not an exception. It is
expected behavior
> that may be accounted for at compile time. Also, in the real world,
> people compile without exception support because of overhead issues.

Cancellation is a runtime concept. There's nothing you can do at
compile time because the cancellation request is made at runtime.
Worse, if asynchronous cancellation is allowed the request can occur
ANYWHERE within a running thread, which will make the overhead of
exceptions pale in comparison.

> FYI: ACE has cancelation. Maybe we should have a look at it.

I have looked at ACE, and they don't address the issues at all.
Bill Kempf

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