Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 12 Apr 2000 00:07:40 -0700 (PDT)
From:      Ming Zhang <ming@yahoo-inc.com>
To:        Arun Sharma <adsharma@sharmas.dhs.org>
Cc:        hackers@freebsd.org
Subject:   Re: Multithread safe gethostbyname() ?
Message-ID:  <Pine.BSF.4.10.10004112344320.86949-100000@pious.yahoo.com>
In-Reply-To: <200004120538.WAA17491@sharmas.dhs.org>

next in thread | previous in thread | raw e-mail | index | archive | help

On Tue, 11 Apr 2000, Arun Sharma wrote:

> In muc.lists.freebsd.hackers, you wrote:
> > 
> > Is there a MT-safe implementation of gethostbyname() in FreeBSD (3.4/4.0)?
> > 
> > On Solaris there is gethostbyname_r().  Calling gethostbyname() with in
> > two threads cause both threads to block.
> 
> You seem to be talking about two different things:
> 
> 1. A reentrant function - two different threads can be in the same function
>    simultaneously
> 
> 2. A non blocking function.
> 

Hi, thanks for the reply.  I'm talking about (1). Reentrant functions
are MT-safe, but a non blocking function may not be.

> Reading the code in /usr/src/lib/libc{,_r}, it appears to me that, the
> FreeBSD implementation is not reentrant, and blocking. However,
> gethostbyname calls poll(2), which causes a reschedule to another runnable
> pthread, if any.
> 

Sure, and there is no "reimplementation" for gethostbyname() in libc_r as
far as I could tell.

> In your case, both the threads are waiting for a DNS server response,
> so the thread scheduler doesn't have a thread to schedule.

If I only create one thread, then the gethostbyname() returns immediately. 
By using truss -p, it seems that gethostbyname() uses a static socket var
for the DNS I/O rather than a local one, and that I think is what caused
the threads to hang.  Or, we're talking about the same thing?

Thanks again for the input.

Ming

> 
> I think it'd be very useful to have a non-blocking DNS lookup API (one
> which exposes the underlying file descriptor) . Winsock has this. UNIX
> netscape 4.x would freeze half as often if this was done right.
> 
> 	-Arun
> 



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?Pine.BSF.4.10.10004112344320.86949-100000>