cancels a running resolver job. When it returns, the client structure
is safe to discard.
.PP
-The resolver is currently implemented using a pool of server processes.
-Incoming resolver jobs are passed to an available server, or a new
-server is started if all are busy. There is a maximum number of
-servers, and jobs are queued once this limit is reached. Old servers
-which have been idle for a period of time are killed off. Servers are
-also killed if they start misbehaving or their jobs are aborted.
+There are two versions of
+.BR bres .
+The standard one uses a pool of server processes. Incoming resolver
+jobs are passed to an available server, or a new server is started if
+all are busy. There is a maximum number of servers, and jobs are queued
+once this limit is reached. Old servers which have been idle for a
+period of time are killed off. Servers are also killed if they start
+misbehaving or their jobs are aborted.
.PP
By default, servers are started simply by calling
.BR fork (2).
is the full pathname of the server program, or null to accept the
default set at library configuration time (which is usually correct).
.PP
+The other implementation of
+.B bres
+uses the
+.B adns
+library to do asynchronous resolution. It can cope with many more
+simultaneous resolver jobs, and doesn't use up external processes. If
+you're using the
+.BR adns -based
+resolver, then the
+.B bres_exec
+function does nothing at all.
+.PP
For security reasons, when an address is resolved, the hostname received
is verified by performing a forward lookup. If the forward lookup fails
to return the expected IP address, an error is reported.
.BR sel (3),
.BR mLib (3).
.SH "AUTHOR"
-Mark Wooding, <mdw@nsict.org>
+Mark Wooding, <mdw@distorted.org.uk>