From owner-freebsd-hackers Fri May 31 15:30: 5 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from falcon.mail.pas.earthlink.net (falcon.mail.pas.earthlink.net [207.217.120.74]) by hub.freebsd.org (Postfix) with ESMTP id BCDD337B406 for ; Fri, 31 May 2002 15:29:55 -0700 (PDT) Received: from pool0324.cvx40-bradley.dialup.earthlink.net ([216.244.43.69] helo=mindspring.com) by falcon.prod.itd.earthlink.net with esmtp (Exim 3.33 #2) id 17DutA-0000Zo-00; Fri, 31 May 2002 15:28:53 -0700 Message-ID: <3CF7F902.3E991E79@mindspring.com> Date: Fri, 31 May 2002 15:28:18 -0700 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Peter Haight Cc: Clint Olsen , hackers@freebsd.org Subject: Re: Is gethostbyname2() reentrant? References: <200205312101.g4VL1vvj057289@wartch.sapros.com> 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 Peter Haight wrote: > >On May 31, Peter Haight wrote: > >> If I link with libc_r can I use gethostbyname2() at the same time in two > >> different threads? > > > >Pardon my ignorance, but how does re-entrancy affect this? It would seem > >that you're interested in a function that doesn't block. > > The function returns a pointer to some sort of memory. I'm worried that the > the two separate requests could possibly mess up each others memory. Maybe I > have the terminology wrong. The gethostbyname() is just a wrapper to the gethostbyname2() function, that supplies the "address family" parameter automatically. The memory is a static struct hostent which is declared and then has it's address returned in /usr/src/lib/libc/net/gethostbyht.c . So no, the calls are not permitted to occur concurrently. You may be able to achieve concurent calls by calling ndispatch() directly after assembling your own request, if you use the bind9 resolver libraries instead of the FreeBSD libc resolver code (it depends on whether it's been made thread safe since the last time I looked at the code). Alternately, you can write your own resolver library. If you are attempting to do this to make lookups faster (bounded by the timeout for bad resolvers for INET6 addresses, for example ;^)), you will need to do that. If, on the other hand, the intent is only to permit outstanding requests to exist simultaneously, and not necessarily truly concurrently, you can go to "apartment model threading", and/or serialize access to the interface ("rental model threading"). Serializing access is obvious. Apartment model establishes a thread to do the lookup work, and you queue requests to that thread; it services them (usually in FIFO order), and then posts a wakeup on the result buffer for you, after copying them out. Which model is best really depends on the structure of your code, and your expecatation of whether or not truly reentrant routines will end up being concurrent, or not. At some point, I expect that DNSSEC will become widespread (Verisign basically bought the top tier DNS, so it's reasonable to expect they will force this to happen at some point). When that happens, we will problably see most requests for recursive lookups and for DNS forwarders become TCP requests instead of UDP requests, because of their size. So I expect there will be a limit on the number of concurrent outstanding unsatisfied requests that wil end up being smaller for TCP than you might expect for UDP (e.g. each TCP will require an fd/socket pair; UDP doesn't have that requirement). That basically implies that, eventually, the apartment model for threading is going to win (I rather expect that using threading to scale is going to fall by the wayside, and be replaced with async NS interfaces before that happens, so this whole thread thing is really a "make-work" anyway). -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message