Date: Fri, 31 May 2002 15:28:18 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Peter Haight <peterh@sapros.com> Cc: Clint Olsen <clint@0lsen.net>, hackers@freebsd.org Subject: Re: Is gethostbyname2() reentrant? Message-ID: <3CF7F902.3E991E79@mindspring.com> References: <200205312101.g4VL1vvj057289@wartch.sapros.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3CF7F902.3E991E79>