Bind 8.2 and thread specific resolver state
Adam D. Bradley
artdodge@cs.bu.edu
Fri Dec 3 07:40:00 GMT 1999
On 3 Dec 1999, Andreas Jaeger wrote:
> I do have one design problem with the integration of the BIND 8.2
> code. Adam suggested to use a thread specific resolver state and
> added struct __res_state to _pthread_descr_struct. The problem is
> that struct __res_state contains internally already h_errno as:
> int res_h_errno; /* last one set for this context */
>
> and _pthread_descr_struct also:
>
> int * p_h_errnop; /* pointer to used h_errno variable */
> int p_h_errno; /* error returned by last netdb function */
> ...
> struct __res_state *p_resp; /* Pointer to resolver state */
> struct __res_state p_res; /* per-thread resolver state */
>
> What is the right thing to do? Do we need h_errno for old
> programs (binary compatibility)? Or can we just redefine
> __h_errno_location to return the thread specific res_h_errno instead
> of h_errno? I fear this doesn't work since h_errno is part of the
> exported interface of glibc:
> gromit:~/ELisp/pgnus:[0]$ nm /lib/libc.so.6 |grep h_errno
> 000c8d10 W __h_errno_location
> 000f59c4 W _h_errno
> 000f59c4 D h_errno
It was my understanding that _pthread_descr_struct is strictly an
_internal_ interface for glibc, and that no application should know/care
about it. The weak symbols in the libc binary are the default (simple)
int and pointer for the non-threaded case; on threaded compiles, h_errno
et al get mapped to macros/fns that look inside of _pthread_descr_struct.
So we should be able to strike h_errno from that struct and have all the
macros/access fns just use the one inside of the __res_state.
Of course, we then need to update everything that uses p_h_errno or
p_h_errnop, but I think they're (almost) always used via macros like
__set_h_errno so that shouldn't be hard.
Adam
-- Adam D. Bradley -- artdodge@cs.bu.edu -- BU x8921 MCS211 --- <>< ---
This message has been infected with a .signature virus. \ www.adbp.org
Copy it into your .signature file or the turnip dies!!! \ 2Cor6:12-13
More information about the Libc-alpha
mailing list