Re: PATCH: back-sock

[Brian Candler <B.Candler@pobox.com>]

On Thu, Oct 13, 2005 at 03:24:58PM +0200, Hallvard B Furuseth wrote:
> Brian, you have a name conflict with at least print_suffixes() and
> read_and_send_results() in back-shell.  You can prefix the names with
> sock_, or maybe reuse some back-shell code similar to how back-hdb
> reuses back-bdb code.

Ah, I hadn't tried compiling both at once :-) I'm working on tweaking the
patch for 2.3.11 now.

> Regarding future development:
> 
> Opensock() says:
> 
> > * FIXME: count the number of concurrent open sockets (since each thread
> > * may open one). Perhaps block here if a soft limit is reached, and fail
> > * if a hard limit reached
> 
> Or defer the operation a little and try again later, with some
> timelimit for how long to wait.

I think that's what I meant by 'block', although I'd rather avoid having to
spin and poll. Perhaps there's an object like a semaphore it could wait on,
and have the thread library wake us up when we're ready to continue.

My knowledge of threaded programming in C is minimal... that's why I like
prefork libraries :-)

> At the same time, you could add code to retry a few times if connect()
> fails because no worker process is listening to the socket file.
> Otherwise, if you start slapd and the worker process at the same time, I
> think the first LDAP requests can fail if slapd starts up quicker than
> the worker process.

That's possible, although that particular problem goes away if you start the
worker pool before slapd.

> Such a change might also allow the admin to kill and restart the worker
> process without restarting slapd, and with no LDAP operation failures.

Indeed. What do other backend modules do? For example, if you're running
back-sql and you stop the SQL server for 5 seconds, do the requests back up
and automatically retry, or do they return LDAP_UNAVAILABLE to requests
during that period?

Regards,

Brian.