thread safety requirements in MIT krb5 libraries

[Jeffrey Hutzelman]

On Thursday, December 18, 2003 08:22:07 -0500 Miro Jurisic 
<meeroh at meeroh.org> wrote:

>> There's another kind of cancellation that might be desirable too.
>> If thread 1 manages a GUI with a cancel button, and thread 2 is
>> waiting for packets from the nameserver or KDC, or is running a long
>> calculation to generate a key, thread 1 may want to tell thread 2 to
>> stop what it's doing.  Cancelling the entire thread is one way of
>> doing that, but might we want to be able to cancel just the current
>> operation, and propagate that fact up to the caller?  This is
>> probably a question for people working on long-running Mac and
>> Windows GUI programs; UNIX guys like me just hit control-C in our
>> terminal windows. :-)
>
> In a C++ application, this is the only correct way to perform thread
> cancellation, as it is the only way to correctly clean up the stack.
> Normally, it's done by having a top level exception handler in the
> thread, and throwing a thread-cancel exception from the place where
> cancellation was detected (usually right after a call to a blocking API).
> This is generally also true for any C application with resources on the
> stack (pointers, file descriptors), as it's a lot easier to crawl up the
> stack propagating a thread-cancel error than it is to figure out what to
> release and then summarily execute the thread.

Except that each thread has a stack of cancellation cleanup handlers, which 
can be pushed as resources are acquired, and popped as they are released. 
This makes it pretty easy to handle cleanup before the thread is cancelled, 
even in a language like C that doesn't have exceptions.

-- Jeffrey T. Hutzelman (N3NHS) <jhutz+ at cmu.edu>
   Sr. Research Systems Programmer
   School of Computer Science - Research Computing Facility
   Carnegie Mellon University - Pittsburgh, PA