[Date Prev][Date Next] [Chronological] [Thread] [Top]

connection management issues



I am working on changes to resolve two race conditions in slapd.   The first
condition is requests posted immediately after a bind may not use new binddn.
The second race condition has to do with shutdown sessions with outstanding
operations.

I've come to the conclusion that to resolve the these condition will require
significant restructuring of the connection management issues.   To resolve
the bind issue, slapd needs to keep same connection operations posted after
receiving the bind pending until the bind completes.  This could be done by
blocking new connections, but this would block the listener which might
deadlock the connection (if it has a write pending).

I've come to the conclusion that I need a queue of hold pending operations
while waiting for the bind to complete.  When the bind completes, then this
queue is flushed.

There are two basic ways this could be handled.

1) The thread which just completed the bind could flush the queue (spinning
off new threads for each pending operation).

2) A thread pool could be implemented which supported pending operations.
The thread which just completed the bind would just run though pending
operations to update their status to 'runnable'.

I believe both are about the same level of complexity and would require
similiar amounts of time.   With option 1, we maintain -DNO_THREAD but do not
make any significant architectural improvements.  With option 2 we gain a
thread pool, but lose -DNO_THREAD support.

Comments?  Suggestions?

Kurt