Re: first sight

From: bill_kempf (williamkempf_at_[hidden])
Date: 2002-01-15 12:05:40

--- In boost_at_y..., Lee Brown <lee_at_a...> wrote:
> Thank you all, this "thread" ("Hey! I made that funny" a la Foghorn 
Leghorn) 
> has been very insightful to me.
> 
> These are things as I see them. I know nothing of Windows.
> I am quite conversant with Posix threads and thread issues in 
general.
> 
> 1) Thread cancelation comes in three flavors: immediate, deferred, 
and 		
> ignored. Immediate means one thread cancels another and the other 
immediately
> exits.  Deferred means the other doesn't exit until it hits a 
cancelation 
> point. Ignored means cancelation is not possible(honored). Boost is 
ignored 
> mode capable only.

I know these modes under the names asynchronous, cooperative and 
disabled, but these are the three modes we've discussed in 
this "thread" (to borrow your funny).  Today Boost.Threads supports 
only ignored/disabled (a unique way to look at it... I'd prefer to 
say it simply doesn't support cancellation).  However, there are 
plans to support cooperative/deferred as well.

> 2) Immediate cancelation is not possible without a thread being 
able to put 
> itself into defer or ignore state and back again.
> 
> 3) Cancelation is not possible without a resource cleanup stack.

More importantly, this "stack" must be the traditional C++ stack, 
insuring that all destructors are called.
 
> 4) If cancelation is in effect, resources should be aquired and 
released in 
> the same scope and in reverse order.(FYI: I believe reverse order 
is the only 
> important fact,  same scope merely ensures this. This is the 
bizarre 
> implementation of pthead_cancel_push() and pthread_cancel_pop())
> 
> 5) Thread cancellation is NOT an exception. Period. It is an event 
to
> be handled.  In fact I believe Xavier Leroy implemented 
thread_cancelation 
> through a signal handler.  Thread cancelation was merely a special 
case of 
> sending a signal to a thread. 

Cancellation *IS* a form of an exception.  Or to be put another way, 
the behavior of cancellation must be identical to the behavior of an 
exception being thrown (possibly barring the ability for a user to 
catch the "exception").  In other words, it must unwind the stack in 
the same manner that an exception does.  Any other implementation in 
C++ is unusable.  This is one of the pains of using POSIX in a C++ 
program today.
 
> 6) Actually, these mailings have reinforced my opinion that 
cancelation would 
> be quite safe and easy to implement in C++ (at least in UNIX), with 
simple 
> rules to keep everything cancel safe. I think policy based 
programming would 
> really help here as Andrei shows it helps concurrent in general. Of 
course 
> its hard to know until it is done because multithreaded stuff can 
be subtle.
> 
> i.e.
> 
> thread_routine()
> {
>   cancel_safe_lock l(mutex_);
> 
>    smart_ptr<Object> o =      
> CreatePolicy<Object,cancel_safe_thread_policy>create();
> }	
> 
> Then again maybe I'm an idiot.

Cooperative/deferred cancelation most certainly can be done safely 
and effectively in C++.  Doing so portably puts a few constraints on 
us.  For instance, Boost.Threads is going to have to use an actual 
C++ exception here (I believe), while the standard could just use 
a "kissing cousin" to the exception (i.e. the standard could make the 
type non-catchable).

Asynchronous/immediate cancellation, on the other hand, poses several 
more issues.  It's highly dangerous to use in C++ (actually, in any 
language, IMHO), but it can provide an optimization in certain cases, 
so may be desired despite the dangers.

Bill Kempf