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] |
I've basically done all the work to update the resolver to BIND-8.2.3-TB5. This is the current beta release, and <http://www.isc.org/products/BIND> says that "This is prerelease code and is not intended for production use." However, the announcement says that it is a release candidate, and the code contains some bug fixes and real improvements, so I'm pretty confident that we can safely use this code. And I intend to closely track the official BIND distribution and update glibc accordingly. However there are some things I'd like your opinion on: * I've tried to reduce the diffs with the official BIND sources to a minimum. This means that my patch will contain some gratitious white-space changes and that I've reintroduced __P is <resolv.h>. The rationale being that it is easier to spot any real changes when imporing a new BIND version. * I've changed all RCS $Id$ strings into $BINDId$. This should prevent CVS from doing its keyword substitution, such that we retain the origional version information. Again this makes it easier to spot which files have been changed in BIND with respect to the previous import. * I've changed the implementation of how the resolver behaves in a multi-threaded context as follows: 1. The "old" thread-unsafe interfaces (e.g. res_init(), res_query(), res_search() etc.) always act on a static resolver state (the global variable _res). 2. All threads, except the main thread, have their own resolver state, and _res is a macro that uses the function __res_state() to get the per-thread resolver state. The main thread continues to use the static resolver state in the global variable _res (which is normally hidden by the _res macro). The motivation for this setup is that it makes it possible to use legacy code that uses the "old" interfaces in the main thread without any problems (including setting _res.options before calling res_init()). Solaris has a similar restriction. Even code that sets _res.options in the main thread and calls the "old" interfaces in other threads will still work as expected if locking is used to prevent two threads from concurrently using the static resolver state. Modifying _res.options in other threads will seem to have no effect when using these "old" interfaces. To be really thread-safe, programs should use the new interfaces of course. The macro _res is there for their (and our, since we use it in the dns NSS module) convenience to avoid the need of allocating their own. Of course this was already how Andreas implemented things, except that for some curious reason he modified res_libc.c such that res_init() now uses the thread-specific resolver state, whereas the rest of the old functions still use the static resolver state. That cannot be right, and I think that's why people noticed some problems. If people agree with this, I'll try to wrap up some documentation. * BIND-8.2.3-TB5 uses a double underscore on all exported functions. Are there strong reasons not to do this? If not, I'll add an alias for the old symbols that didn't have the double underscore and additionally export the double underscored version, and I'll export those new functions that are documented in the resolver(3) man page that comes with BIND-8.2.3-TB5 with a double underscore. I think this might avoid some problems with programs that link with libbind (which also contains the reolver code and use our dns NSS module. The alternative is to export all documented symbols without the double underscore, and add aliases for those symbols that were previously exported with a double underscore. Mark
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |