Martin Rex wrote: > Ken Raeburn wrote: > > > > I'm actually working on thread safety for the MIT code right now, > > and I'm pretty much having to guess. > > Well, Good Luck! > > When we had a discussion on multi-threading on CAT (but I think it > was rather a conversation
Oops, I seem to have forgotten to complete this part. The issue of multithreading came up several times on CAT, but was never thoroughly discussed because it was considered out-of-scope for v2 and there was little experience with multi-threading issues (but a lot of known pitfalls). Ted Ts'o mentioned once that the MIT Kerberos codebase was not written with multi-threading in mind and that he was not convinced that the code could be made thread-safe with only a small amount of changes, but rather require serious and tough work. Several Unix platforms had only user-mode threading (i.e. non-preemtive) if any before 2000. And even today there are platforms that have multiple incompatible thread libraries (and AFAIK that includes Linux). In the early days there were extreme incompatibilities between single-threaded and multi-threaded compiled code, including different libc versions (and loading more than one libc instance in a process on Unix is bound to cause problems because of the global symbol space). This was mostly because multi-threading came as an add-on for existing releases of an OS. Today's Unix often come with a single libc that works in both single-threaded and multi-threaded environments, and there's some magic that makes the system loader recognize whether malloc() and friends need to use locking or not. Even with the libc loading problem solved on a few platforms, there still is the issue of traditional extern int errno; vs extern int *___errno(); #define errno (*(___errno())) as a difference between single and multi-threaded code and this is probably an issue for multi-threaded apps using a gssapi mechanism that was compiled single-threaded. -Martin -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to [EMAIL PROTECTED]