Ticket 5338: Race conditions in key rotation

[Nicolas Williams]

On Mon, Jun 23, 2008 at 07:16:42PM -0400, Ken Raeburn wrote:
> On Jun 23, 2008, at 18:03, Nicolas Williams wrote:
> >It would help too if krb5kdc were multi-threaded, otherwise clients
> >can time out if too many hit the master at once, and meanwhile the
> >master is not maxing either its CPU nor its I/O.
> 
> We've gotten requests (and arguments) both pro and con...
> 
> [...]
> 
> On the flip side, there's the argument that going from single-threaded  
> code to multi-threaded is likely to introduce race conditions into  
> existing code if you're not *extremely* careful, and they'll be hard  
> to spot.  Using a multi-process model could conceivably work, but also  
> requires some careful re-architecting, though without as much risk of  
> memory-corrupting race conditions.

Personally I'd prefer that you implement a single-threaded-but-async KDC
first.  Threading that will be easier, but at least you'll be abe to max
out (or get close to maxing out) one CPU and all the I/O that can drive.

This mostly means breaking up a couple of functions around all kdb
operations.