"Paul B. Henson" <[email protected]> writes: > As I understand it, the issue is that there is no "get a lock, wait in > line if it's not available" call.
What I was alluding to was operations like the F_SETLKW (as opposed to F_SETLK) command of POSIX fcntl(), which will block on acquiring the lock. It has a drawback of lacking timeout capability, so callers would have to arrange for a timeout by using alarm() or something. This isn't really viable in a multithreaded process, or in a library, but we can probably make it work because currently none of the processes involved are multithreaded. (I'd have to check whether the recent libverto integration will add complications for kadmind, though.) > The current approach tries five times with a 1 > second delay in between tries to get the lock, then gives up. If > somebody else (in this case kadmind) is also busily grabbing the lock, > and sitting on it, the odds of you getting in to get it aren't > necessarily that good. The kprop process is probably also fighting with the main KDC process in acquiring the lock, so if you have a heavy authentication load going on at the same time, the problem could get worse. ________________________________________________ Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
