Date: Mon, 02 Dec 1996 15:36:04 -0800 From: John Polstra <jdp@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 Message-ID: <199612022336.PAA00788@austin.polstra.com> In-Reply-To: Your message of "Mon, 02 Dec 1996 13:27:07 %2B0300." <199612021027.NAA00901@nagual.ru> References: <199612021027.NAA00901@nagual.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199612022336.PAA00788>