Multithreading the KDC server - a design

Morrison, Wayne wayne.morrison at
Mon Apr 4 15:26:09 EDT 2005

On Monday, April 04, 2005 3:00 PM Roland Dowdeswell [elric at] wrote:

> 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

Forking is *MUCH* more of a problem in our environment than threading.  It most certainly does NOT make porting easier for us, and has to be redesigned/rewritten for our port.  What you're proposing would, unfortunately, be a nightmare for us.

I realize that most of the actual implementations are on UNIX or UNIX-like platforms, but there are some (OpenVMS or Windows, for example) that do not have the same tools to work with.  Consider this a request to use mechanisms that are standard across all the ported platforms as much as possible.


More information about the krbdev mailing list