> > The res_send.c code in glibc2.1.1 (and all prior versions, inc 2.0.x)
> > resolv library looks fundamentally broken for any threaded environments.
> > There are gaping, wide-open race conditions.
>
> libresolv in glibc (both 2.0 and 2.1) is BIND 4.9.something more or
> less verbatim. I'm not at all surprised to hear that it's not thread
> safe.
>
> BINDv8 *appears* to have been made thread safe - this is me doing a
> cursory inspection, not a formal check. I was planning to update
> libc's code, but it doesn't look like I'm going to have time anytime
> soon. If you are interested in doing it, I'd be happy to lend a hand
> and see it gets into the official release.
I've submitted a bug report to the glibc list; there seems to be at least
token interest in getting it done. Just for kicks, I pulled down
bind8.2.1 from ISC, and linked my program against libbind_r.a instead of
glibc's libresolv, and it seems to work almost out-of-the-box. I imagine
the real trick willbe integrating it with glibc's "way of doing things",
nscd, etc...
Any notes you may have on the subject would certainly be welcome. My
summer job is affording me more spare time in the evenings than my usual
graduate student schedule does, so I'll be happy to try my hand at it.
Adam
-- Your lives aren't small, but \ Adam Davenport Bradley, Grad Student you're living them in a small \ Boston University Computer Science way. Live openly and expansively! \ artdodge@cs.bu.edu 353-8921/MCS211 II Cor 6:12-13 (The Message) <>< \ http://www.netwinder.org/~artdodgeHi! I'm a signature virus! Copy me into your signature so I can spread!!
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/