Re: threadsafe name resolution
Greg Thompson wrote: 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. I've been working on fleshing out the _r routines for quite some time now. I've done all the easy ones, and the ones you're looking for are just screaming butt-ugly. It would be simple enough to create a mutex-protected variant of each, but that's not nearly as good a solution as make a REAL _r implementation. If you have implementations to offer, I'd be quite happy to review and commit them. I haven't had enough spare time to even crack the code in months now, unfortunately. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC [EMAIL PROTECTED] http://softweyr.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
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. -- -greg Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
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
RE: threadsafe name resolution
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
Re: threadsafe name resolution
On Wed, Aug 09, 2000 at 12:07:01PM -0600, Charles Randall wrote: Is there a reason that ADNS won't work for this? Firstly, adns doesn't do IPv6 (at least not yet, according to the web page you gave). Secondly, I'm not sure if it's thread safe (although being nice 'n async it's not hard to use it in threaded apps even if it isn't). Thirdly, adns is GPLed, which means you'll have a hell of a job getting people to include it into the base system. -- Mike Bristow, seebitwopie To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: threadsafe name resolution
From: Charles Randall [EMAIL PROTECTED] Is there a reason that ADNS won't work for this? http://www.chiark.greenend.org.uk/~ian/adns/ in addition to the other reasons mentioned, it won't work for me because it's not a part of the os. as an application developer, i'd expect the basic services to work without me having to grab random packages to solve already solved problems. someone else pointed out that the old gethostbyname/addr pair isn't threadsafe. i realize this. what i was suggesting is that someone could perhaps implement gethostbyname_r and gethostbyaddr_r. call these a hack if you will, but they solve the problem just fine on other platforms. as long as nothing other than getipnodebyname and byaddr share resources with those two, i'm safe if i just throw a mutex around my calls to byname/addr. unfortuantely, this solution gets the "big suck" rating. if the operating system ships with mechanisms that are documented as being thread-safe, they should be. if they're not, it should be clearly stated in a bug report somewhere that this is the case. i have submitted a bug with KAME. i hope they fix it soon. in the meantime, it'd be nice if freebsd had an alternative. Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: threadsafe name resolution
as long as nothing other than getipnodebyname and byaddr share resources with those two, i'm safe if i just throw a mutex around my calls to byname/addr. unfortuantely, this solution gets the "big suck" rating. if the operating system ships with mechanisms that are documented as being thread-safe, they should be. if they're not, it should be clearly stated in a bug report somewhere that this is the case. i have submitted a bug with KAME. i hope they fix it soon. in the meantime, it'd be nice if freebsd had an alternative. sorry for bad documentation, manpage should be updated to state "the current implementation is not thread safe" in BUGS section. itojun To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: threadsafe name resolution
| Is there a reason that ADNS won't work for this? | | http://www.chiark.greenend.org.uk/~ian/adns/ Technically, no. Morally, it's GNU. :-) -- 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
