hyc@symas.com wrote:
It also occurs to me that we probably don't even need to manipulate the slapd runqueue in persist mode, when si->si_conn is already set. I.e., in that case we can only have gotten here because of a listener event, and not because of a runqueue schedule.
That is probably true.
Right, my patch avoids that now. Having looked at it again I think replacing the trylock with a regular lock is fine.
OK, reverted the trylock (which was put there in rev 1.376). I unfortunately don't remember what prompted that commit; certainly there was no ITS associated with it.