From: Lee Brown (lee_at_[hidden])
Date: 2002-01-14 19:22:02
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.
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.
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.
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.
lee