Re: cvs commit: apache-2.0 STATUS

["Ralf S. Engelschall" <rs...@engelschall.com>]

In article <19...@hyperreal.org> you wrote:

>   A thread (of messages) in comp.programming.threads reminded me of this.
>   Blaaaah
> [...]
>   +
>   +    * We need a thread-safe resolver, at least on Unix.
>   +        Status: The best known candidate would be something from BIND
>   +        (v8 or v9?) The only other option would be to mutex all the
>   +        resolver calls,

BTW, is thread-safety really enough for Apache? I mean this way you more or
less just avoid side-effects caused by preemptive threading. But IMHO for
Apache you also need _asynchronous_ resolving to make sure the server
processes are not blocked out a thread inside the resolver library. Something
like GNU adns, BIND's libares, etc. I think is needed here...

                                       Ralf S. Engelschall
                                       rse@engelschall.com
                                       www.engelschall.com

Re: cvs commit: apache-2.0 STATUS

[Tony Finch <do...@dotat.at>]

"Ralf S. Engelschall" <rs...@engelschall.com> wrote:
>
>But IMHO for Apache you also need _asynchronous_ resolving to make
>sure the server processes are not blocked out a thread inside the
>resolver library.

I'm not convinced that Apache's architecture would allow it to benefit
from an asynchronous resolver. What can a thread do while it's waiting
for a DNS reply?

>Something like GNU adns, BIND's libares, etc. I think is needed
>here...

AFAIK the asynchronous resolver that comes with bind is called arlib
(in the contrib tarball). "ares" is the MIT Project Athena resolver.
ftp://athena-dist.mit.edu/pub/ATHENA/ares

Tony.
-- 
let it be dot at