Multithreading the KDC server - a design

[Sam Hartman]

>>>>> "Ken" == Ken Raeburn <raeburn at MIT.EDU> writes:

    Ken> First, you're talking a lot about 1.3.5.  A bunch of changes
    Ken> went into library code in 1.4 to make it thread-safe, so 1.4
    Ken> would be a much better starting point for the work.
    Ken> Otherwise you wind up having to pull in a lot of the changes
    Ken> between 1.3.5 and 1.4 anyways, or redo a bunch of the work.

I'd like to echo Ken's comments here.  How willing/able we are to take
new code depends significantly on how cleanly that code applies to our
current development sources.  There are cases where we've done
extensive porting efforts but that involves a lot of resources on our
part.  We'd strongly prefer code based on our current development
tree.  There are cases where people contributing code don't have the
resources to do that; we will try to work with people but the effort
we can spend depends on what else is going on and how important
integrating that code is.

I think we would be unlikely to accept thread-related code based on
1.3.x.

    Ken> You don't indicate whether the thread interface you use would
    Ken> be an extension of what I've done so far (which may be a bit
    Ken> complicated to sort through at first glance, I admit), or
    Ken> directly using the POSIX interfaces.  The former would make
    Ken> it easier for somebody to someday port the KDC to Windows, I
    Ken> guess, but extensions would need to be made (e.g., thread
    Ken> creation and monitors are outside of its current scope), and
    Ken> the POSIX approach is likely to get done a lot faster.

I think making the KDC harder to port to windows would be a hard sell
for us.