Re: SLAP_LIGHTWEIGHT_LISTENER

[Howard Chu <hyc@symas.com>]

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
> writes.
>
>   
> >   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.

Yes.

--
 -- 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/