thread safety requirements in MIT krb5 libraries

[Miro Jurisic]

>I don't think the ability to register callback functions for thread 
>system operations will be needed.  It appears that for all the 
>platforms we care about, there's a standard thread system (or more 
>than one, mapping to the same basic OS interface so as to be 
>interoperable).  We were concerned that people might want to be able 
>to use, for example, the Gnu PTH library instead of a native, 
>preemptive pthreads, but I haven't heard many people expressing 
>interest.

I recommend reading 
<http://developer.apple.com/technotes/tn/tn2028.html> before 
proceeding, as it details the assumptions you can make about 
threading models on Mac OS X. A quick reading leads me to believe 
that you are right, but you should double check it.

>Sam suggested we could consider an application restriction that all 
>references to a file must use the same name, i.e., "/var/tmp/foobar" 
>and "/tmp/foobar" would be handled as separate files, even if "/tmp" 
>is a symlink to "/var/tmp".  It would simplify things greatly, and 
>in most cases wouldn't be a problem, but it still makes me 
>uncomfortable.  Using the pathname would, however, be a good first 
>cut -- i.e., we shouldn't need to use fstat to know that two replay 
>caches opened with the same absolute pathname will be the same, 
>given that the replay cache is supposed to refresh from the file if 
>it changes.

Do you have a list of all the APIs in which a file path reference 
crosses the API boundary?

>I believe it's going to be a requirement that we be able to load the 
>Kerberos or GSSAPI library dynamically, do some stuff with it, and 
>unload it, and repeat the cycle, without resource leaks, at least 
>for a properly written program.

This has always been a requirement on Mac OS and Mac OS X, and it was 
usually exercised by SAP. You should note that this requirement 
implies that you cannot use atexit handlers, because if a shared 
library is unloaded, it's usually done before exit() is called.

>It would probably be difficult, if not impossible, to make the 
>library code be async cancel safe.  However, making it safe for 
>synchronous cancellation may be doable.  How much do threaded 
>programs actually use pthread_cancel or the Windows equivalent?

I belive that this call was unimplemented on some versions of Mac OS, 
but I am not sure what the current state of that is, as I don't use 
pthreads much

>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.

Of course, most people don't have a clue about this.

>Unless some good reason for it can be presented, none of MIT's 
>Kerberos programs will use threads.

It would maybe make vague sense for ftp or ftpd were it not for the 
fact that the code is a steaming pile of yacc excrement :-)

meeroh
-- 

<http://web.meeroh.org/> | KB1FMP

A: Because it reverses the logical flow of conversation.
Q: Why is top posting frowned upon?