Rein Tollevik wrote:

Howard Chu skrev:

...

How about just moving the enable to after the runqueue manipulation is done?

That would still leave a glitch in the window open, unless the initial trylock is changed to a regular lock as your checking message suggests.

But, doing that could result in all the threads ending up waiting for the lock if do_syncrepl of a refresh only replication is configured to run too often. I assume the trylock is there to avoid this?

Yes, but I don't think that's a problem any more. If the scheduled task is still running when the next interval hits, the daemon task will just reschedule; it won't fire off a new thread for the task.

...

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.