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
> > >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
> can do but usually better and with more typesafety and more
> 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
> 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk