On 11/4/11 4:34 PM, Paul B. Henson wrote: > 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.
There are ways around this, but all involve writing additional code to implement a lock queue (spool dir style, deli counter ticket style, etc.). This code tends to have nasty corner cases that require careful programming, but it's a solved problem. Now whether solving this is worthwhile or not, given the effort required... -- Carson Gaspar ________________________________________________ Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
