From owner-freebsd-hackers  Mon Dec  2 15:37:03 1996
Return-Path: owner-hackers
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.5/8.7.3) id PAA21346
          for hackers-outgoing; Mon, 2 Dec 1996 15:37:03 -0800 (PST)
Received: from austin.polstra.com (austin.polstra.com [206.213.73.10])
          by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id PAA21341
          for <hackers@FreeBSD.org>; Mon, 2 Dec 1996 15:37:00 -0800 (PST)
Received: from austin.polstra.com (jdp@localhost) by austin.polstra.com (8.8.3/8.8.3) with ESMTP id PAA00788; Mon, 2 Dec 1996 15:36:04 -0800 (PST)
Message-Id: <199612022336.PAA00788@austin.polstra.com>
To: =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= (Andrey A.
    Chernov) <ache@nagual.ru>
cc: kuku@gilberto.physik.rwth-aachen.de, hackers@FreeBSD.org
Subject: Re: cvsup can't find host - sometimes 
In-reply-to: Your message of "Mon, 02 Dec 1996 13:27:07 +0300."
             <199612021027.NAA00901@nagual.ru> 
References: <199612021027.NAA00901@nagual.ru> 
Date: Mon, 02 Dec 1996 15:36:04 -0800
From: John Polstra <jdp@polstra.com>
Sender: owner-hackers@FreeBSD.org
X-Loop: FreeBSD.org
Precedence: bulk

> I don't think it is gethostbyname() fail, because everything else
> find it immediately because whole *.freebsd.org cached by my named
> as secondary. Maybe modula soemhow resets intial network search
> sleep (cause it immediately expired?)

It could possibly be something like that.  I am thinking it might be
connected with the multithreading support.  The code disables thread
switching before it enters gethostbyname, so it's definitely not that
gethostbyname is being re-entered.  (Only one of the threads calls it,
anyway.)

But, the threads library uses SIGVTALRM to do preemption of
compute-bound threads.  Perhaps that signal is being delivered within
the resolver code, and causing a problem.  Again, I don't _think_ it
should cause a problem, but it's the only idea I have.  The handler for
the signal will simply return without doing anything (because thread
switching is disabled).  If the signal comes in during a system call,
the system call should resume.  Even if the system call doesn't resume,
the resolver code handles EINTR alright, as far as I can tell.

If it starts failing again, could you try to capture a ktrace of it?

Thanks,
John
--
   John Polstra                                       jdp@polstra.com
   John D. Polstra & Co., Inc.                Seattle, Washington USA
   "Self-knowledge is always bad news."                 -- John Barth