On 11/4/2011 4:10 PM, Tom Yu wrote: > 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
Ah, ok, forgot about blocking fcntl :), it's been a while since I've worked with file locking code. Yah, I've run into issues in the past where I've had an alarm set and something else stomped over it :(. Theoretically I suppose you could try to save the existing SIGALRM handler and remaining time on the current alarm, but that doesn't seem very reliable and rather messy. Also, the success of a blocking lock implementation would depend on whether or not the underlying OS implemented fair lock scheduling. I think Solaris does, but I don't know that Linux (our current OS for kerberos servers) does. > 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. The batch jobs run at 3:30am, so not too much authentication load :). -- Paul B. Henson | (909) 979-6361 | http://www.csupomona.edu/~henson/ Operating Systems and Network Analyst | [email protected] California State Polytechnic University | Pomona CA 91768 ________________________________________________ Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
