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]

Reply via email to