[Date Prev][Date Next]
Kurt D. Zeilenga wrote:
At 10:31 AM 10/14/2005, Howard Chu wrote:
So, the desired approach is:
1: the listener thread listens for reads on wake_sds, listeners, and data connection, and listens for writes on data connections, with a timeout to allow for idle and runqueue processing.
For clarity, listens for writes on data connections with pending
2: if the thread pool gets full, the listener stops listening for reads on listeners and data connections, but continues to listen for reads on wake_sds and writes on data connections.
with timeout as in 1.
3: (optional) if a single connection has many writers queued,
When would a connection have more than one writer queued?
If we're managing write events, there should never be more
than one write worker per connection (excepting the inconsequential
case when one writer has finished but not exited and another
worker on the connection writes).
Sorry, you're right. I was thinking about the previous syncprov, which
delivered psearch responses in the thread of the Modify request. So
multiple writes would result in multiple threads waiting for the psearch
connection. But syncprov doesn't do that any more, and there are no
other instances like that.
Or do you mean that excess amounts of writes are pending for the
one writer to handle?
In that case, the worker queuing more writes can mark the
connection as write-bound and the listener seeing that
can avoid future reads.
-- 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/