From owner-freebsd-hackers Fri Sep 13 8:42:32 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EC34537B400 for ; Fri, 13 Sep 2002 08:42:26 -0700 (PDT) Received: from falcon.mail.pas.earthlink.net (falcon.mail.pas.earthlink.net [207.217.120.74]) by mx1.FreeBSD.org (Postfix) with ESMTP id A740A43E65 for ; Fri, 13 Sep 2002 08:42:18 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from pool0166.cvx21-bradley.dialup.earthlink.net ([209.179.192.166] helo=mindspring.com) by falcon.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 17psa9-0002aJ-00; Fri, 13 Sep 2002 08:42:09 -0700 Message-ID: <3D820700.DB53B0F9@mindspring.com> Date: Fri, 13 Sep 2002 08:40:48 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Jev Cc: freebsd-hackers@freebsd.org Subject: Re: gethostbyname_r() fbsd equiv? References: <20020913145830.GB41842@ecad.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Jev wrote: > Im trying to build some software on freebsd, which wants to use > the thread safe gethostbyname_r(). Despite having very bad C skills im > going to attempt to patch it. What would I use in place of > gethostbyname_r() on freebsd? Do you need the real gethostbyname_r(), or do you need the bastardized Linux version? The real version has the prototype: int gethostbyname_r(const char *name, struct hostent *result, struct hostent_data *buffer); The bastardized Linux version has the prototype: extern int gethostbyname_r(__const char *__restrict __name, struct hostent *__restrict __result_buf, char *__restrict __buf, size_t __buflen, struct hostent **__restrict __result, int *__restrict __h_errnop); So the good one has 3 parameters, and the bad one has 5... It's actually trivial to write this code, IMO. It's also not a very useful exercise, since the resolver code should not be in libc, it should be in a seperate library that is obtained from the third party ISC BIND distribution, and reimported and updated as ISC updates their code. This is additionally complicated by the KAME changes to support IPv6, which have not been standards-tracked into a mainstream resolver library, and anr therefore pretty BSD-hacked-libc resolver specific. If you need a 3 parameter implementation, you should be able to write it in under a day, even including makeing the gethostent and sethostent code, etc., all reentrant (or at least based on code that passes around a context). If you just need to deal with the heap collisions from using gethostbyname() in a threaded program, the most trivial way to implement it is to implement a worker thread to do the lookups, and write a gethostbyname_r() stub that rendesvous with the worker thread to pass off work. This assumes that you don't mind serializing lookup requests through a single thread, which you shouldn't care about unless you are running -current with Jon Mini's KSE based pthreads library, which can take advantage of multiple CPUs, and which would suffer a performance penalty by serializing requests through a single thread. Doing that work should take you about two hours, if you are a competent threads programmer, or just a competent programmer with a copy of the O'Reilly book on pthreads. If you just need *any* gethostbyname_r(), the SQUID distribution has an asynchronous resolver library that implements one. That library, though, is GPL'ed. If you need to avoid the GPL because you don't want to have to GPL the resulting code, then you won't be able to use the SQUID library. Finally, you could always pay someone to do the code for you; if you did that, you would want to specify the interfaces and the required behaviour ahead of time. My personal suggestion would be to find the AIX or HP/UX manual pages, and use them to specify the API, since they do a much better job than the Linux ones (the Linux ones are mostly just the nasty 5 parameter prototypes, with no explanation of the function of the parameters or the expected behaviour in situ). -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message