| 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