Multithreading the KDC server - a design
hartmans at MIT.EDU
Mon Apr 4 17:27:50 EDT 2005
>>>>> "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
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
More information about the krbdev