Howard Chu writes: > It certainly sounds like an improvement over back-shell, and there may > be some value in keeping the perl interpreter outside the slapd process.
Yes: And slapd won't crash if a Perl routine crashes. And perl can be run as a user with none of slapd's privileges, so one need not be too paranoid about running other people's Perl code. 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. 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. 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. Such a change might also allow the admin to kill and restart the worker process without restarting slapd, and with no LDAP operation failures. -- Hallvard
