Howard Chu wrote:
Sounds like we need to do a wake_listener call after inserting the task.
I've just added this in HEAD. But now I'm wondering if using the runqueue here was the right choice; the runqueue is set up to run jobs that are intended to run on scheduled time intervals. For jobs like this where no time interval is involved and we just want it to run right away, it probably should have gone directly to thread_pool_submit.
William wrote:Hi, I am using OpenLdap 2.3.14, with sync mode i meet a question: after the provider and consumer are synced, a client send a modify message to the master, the master updated quickly, but not the consumer until next message received by provider. It seems the provider 'cached' an operation every time. The sequence is like: client provider consumer ---- modify 1 ----> do modify <----- OK 1 ------- ---- any msg 2 ---> <--- result 2 ----- ---- modify 1---> Should the provider modify the consumer as soon as possible ?? I traced slapd. As an overlay, in function 'syncprov_qresp', the provider insert a task(syncprov_qtask) in the runtime list(slapd_rq), which will run after being scheduled. The schedule position is in function 'slapd_daemon_task' (the main loop of slapd), but the loop will be blocked(for the 'select' function is without a timeout) until next message. I add a timeout value to the 'select', and the provider can refresh the consumer soon. But it seems not a good way, is there solution for this question ? Thanks.
-- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/
