This is the mail archive of the libc-hacker@sources.redhat.com mailing list for the glibc project.
Note that libc-hacker is a closed list. You may look at the archives of this list, but subscription and posting are not open.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
The resolver is a bit out of shape at the moment. Ulrich already mentioned that the per-thread _res variable doesn't really work right now: http://sources.redhat.com/ml/libc-hacker/2000-06/msg00073.html and there are some other issues too. I've started to look into these matters, and I'm planning on spending some more time on it, to bring things in working order. The primary goal will still be to provide a fully backwards compatible libresolv.so for single-threaded programs, while providing the necessary infrastructure for a thread-safe libnss_dns. However, I think that the resolver in a multi-threaded program should behave as if one had linked with the libbind from BIND 8. This is somewhat differently from how the resolver in glibc 2.2 behaves right now: * res_init() won't affect the per-thread _res, but instead a static variable, just like the res_mkquery(), res_send(), etc. Right now res_init() sets the per-thread _res, which isn't consistent. * _res will be per-thread, and will be properly initialized in multi-threaded programs (as if res_ninit() had been called on it). I think this means that I can undo some of the ad-hoc patches that have been applied over the last few months. I'll also try to update to the latest and greatest BIND 8.2.3-T5B (which is supposed to be a release candidate). Mark
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |