Is there a reason that ADNS won't work for this?
http://www.chiark.greenend.org.uk/~ian/adns/
Charles
-----Original Message-----
From: Dan Moschuk [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, August 09, 2000 10:51 AM
To: Greg Thompson
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: Re: threadsafe name resolution
| i've just received confirmation from the author of the KAME resolution
code
| that it isn't at all thread safe:
|
| >Sure. As noted in name6.c, thread related stuff is not implemented yet.
| >Since our resolver code based on bind4 doesn't aware thread safeness,
| >all I can do now would be only putting mutex, anyway.
|
| sure enough, name6.c says:
|
| /*
| * TODO for thread safe
| * use mutex for _hostconf, _hostconf_init.
| * rewrite resolvers to be thread safe
| */
|
| now, i'd say that it's fairly important for some form of threadsafe name
| resolution to exist. until the KAME code is fixed, how about adding in
the
| ipv4 _r methods that have been discussed from time to time? or, at the
very
| least, put something in the manpage for getipnodebyname and friends
| indicating that the funcs are not threadsafe.
|
| as you can probably tell, i wasted several hours worth of work bumping
into
| this problem.
The problem lies deeper than that. Calls like gethostbyname() and friends
are not threadsafe either, as they use an internal struct hostent and return
a pointer to it (that another thread would happily clobber with its own
data). Thread-happy functions we're supposed to be added by the Vixie
people,
and since I haven't checked up on it in about a year, they could be in
there by now, but since we use BINDs name-resolver library, it's a contrib/
issue and our policy isn't to hack up the contrib/ tree.
Of course, the door is always open for you to write the code and submit
it to the bind team. 8)
-Dan
--
Man is a rational animal who always loses his temper when he is called
upon to act in accordance with the dictates of reason.
-- Oscar Wilde
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
