kadmin incremental propagation full resync multiple processes spawned

[Carson Gaspar]

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