kadmin incremental propagation full resync multiple processes spawned
Carson Gaspar
carson at taltos.org
Mon Nov 7 16:30:28 EST 2011
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
More information about the Kerberos
mailing list