Re: first sight

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 
support
> > >>  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, 
multithreading 
> capabilities are
> a fundamental element of programming especially for general purpose 
languages 
> like C++. Multithreading is supposed to be a primary selling point 
because 
> C++ is frequently used for servers which dispatch many tasks 
simultaneously.
> 
> 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 
cancellation.

> > 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, 
many 
> 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