Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/17/84; site godot.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!mhuxj!mhuxn!houxm!ihnp4!godot!bruce
From: bruce@godot.UUCP (Bruce Nemnich)
Newsgroups: net.bugs.uucp
Subject: Re: Re: hung line help needed
Message-ID: <582@godot.UUCP>
Date: Fri, 7-Dec-84 11:52:55 EST
Article-I.D.: godot.582
Posted: Fri Dec  7 11:52:55 1984
Date-Received: Sat, 8-Dec-84 05:28:10 EST
References: <85@daemon.UUCP> <33700001@trsvax.UUCP> <2923@allegra.UUCP> <542@godot.UUCP> <2933@allegra.UUCP> <1479@umcp-cs.UUCP>
Reply-To: bruce@godot.UUCP (Bruce Nemnich)
Organization: Thinking Machines, Cambridge, MA
Lines: 17
Summary: 

I fixed the window of vulnerability in my sleep(3) as soon as you
pointed it out.  It doesn't help with the hung line problem though (I
didn't expect it to, since it is not getting hung in sleep()).

I have exactly the same situation as mentioned before.  My outbound
uucico occasionally gets hung in a read(2) system call.  The read
timeout SIGALRM is pending, but SIGALRM is blocked (*only* SIGALRM is
blocked).

I don't understand how SIGALRM could get blocked at any time in uucico.
I grepped through the uucico and libc code, but I noticed no sigblock()
or sigsetmask() calls other than the one I recently added to sleep(),
and we know that's not the problem.  That leads me to suspect a 4.2
kernel bug which is resulting in a spurious mask of SIGALRM.
-- 
--Bruce Nemnich, Thinking Machines Corporation, Cambridge, MA
  ihnp4!godot!bruce, bjn@mit-mc.arpa ... soon to be bruce@godot.arpa