Removal of bogus gethostbyaddr_r()

[Terry Lambert]

David Xu wrote:
> > > It lies?  (_r).
> >
> > If that's true, then it's a bug and eventually should
> > be fixed.  Additionally, you can't go around removing
> > public interfaces without bumping library versions
> > (unless said interface hasn't seen a release yet).
> 
> I think those *_r interfaces are not very useful except
> bloating library. why do not improve non _r version to use
> thread local instead to make them reentrant between threads ?

Nameserver services are incredibly problematic to make thread
safe.

For example, you can't serialize responses, and you have to
support both UDP, and, if the UDP response claims that the
request was too large, you have to connect using TCP, and
disconnect, etc..

As one example, suppose you have two requests outstanding,
one for "A.COM" and the other for "C.NET", and you get a
response from one that claims to be authoritative for the
other, thus poisinging your outstanding response list?

The net effect is that you are running a DNS proxy cache,
with unrolled loop, in your *_r() routines, and you have to
do everything a proxy cache would do on behalf of its clients.

The problem with your approach here is that things like
sockets aren't thread-local.  It wouldn't make much sense for
a multithreaded Apache to have a UDP socket per thread before
it's allowed to use DNS services.

One approach to resolving the issue would be to serialize the
access to a request queue, and throw off some number of threads
in order to handle library consumer responses, each with its
own context statite (doesn't matter if if's thread local
storage, or just an array of structures indexed by start order
and parameter, or using a set of auto's allocated in the thread
main, of the stack, which is also thread local, by definition),
which would include a separate UDP socket.

Doing this has a problem, though, in that you now require
threads to use the interface, even if your program's a finite
state automaton with multiple concurrent contexts, but no
threads: you can't have an unthreaded program.

The upshot of all this is that there's going to be a lot of
work involved no matter how you slice it (the best suggestion
so far, the last time this question came up, is to use some
sort of "lookupd", similar to Apple's Darwin, and make the
messaging interface thread safe and the lookupd a smart DNS
proxy server).

Predominant wisdom has been to let the Bind people solve this
for us, when they release their Bind-9 resolver library release
version (what there is of the current stuff is beta).

-- Terry