[snip statement about serial nature of resolv on linux]
> err.. its not.
>
> .. at all .. as in: it would actually be quite hard to make it that
> way even if you wanted to.
>
> what made you think it was?
I've managed to find a link that describes it in more detail,
http://cs-people.bu.edu/artdodge/linux/glibc/resolv/
In part it says,
The libresolv library distributed with glibc2.1 suffers from some
fundamental defects when linked against threaded programs. Namely,
it's not thread safe. What this effectively means is that if your
threaded program is linked against glibc 2.1.0, 2.1.1, or 2.1.2,
and it calls gethostbyname_r() from more than one context (i.e. two
calls to it can be in-scope simultaneously), your program may see
unusual results, the most common of which being some threads will
get wedged inside a poll() in gethostbyname_r() and never return.
A correctness fix for this problem is in glibc2.1.3, but it is almost
worse than the problem - it forces serialization of all name server
queries, eliminating the race condition from the original code, but
eliminating any parallelism between sleep-intensive and potentially
high-latency name lookups. This causes the performance of many
lookup-intensive programs to (technically speaking) suck.
It also goes on to say that this is fixed in glibc2.2 which I guess
answers my original question.
Cheers
Pete
--
SLUG - Sydney Linux User Group Mailing List - http://slug.org.au/
More Info: http://slug.org.au/lists/listinfo/slug
