Multithreading the KDC server - a design

[Roland Dowdeswell]

On 1112637414 seconds since the Beginning of the UNIX epoch
Sam Hartman wrote:
>

>Hi.  I think this comment comes from missing some conte xt from a
>discussion a few weeks ago.  Note that the goal in multi-threading the
>KDC is not to take advantage of multiple CPUs.  The goal is to have
>multiple execution contexts available so that while one execution
>context is waiting for remote database access another execution
>context can be processing a request.

Given that the KDC itself does not really need to maintain state,
wouldn't it be substantially easier to simply fork off $n$ children
directly after binding to all of the listening sockets and process
requests separately in each child?  The approach works quite well
for a number of other projects and:

	1.  eliminates porting difficulties with subtly
	    incomatible threading implementations, and

	2.  provides a protected address space for each
	    child.

It even let's one use multiple processors, although as you point
out the KDC isn't generally a performance bottleneck.

--
    Roland Dowdeswell                      http://www.Imrryr.ORG/~elric/