Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site umcp-cs.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!godot!harvard!seismo!umcp-cs!chris
From: chris@umcp-cs.UUCP (Chris Torek)
Newsgroups: net.bugs.uucp,net.bugs.4bsd
Subject: Re: Re: hung line help needed
Message-ID: <1409@umcp-cs.UUCP>
Date: Wed, 28-Nov-84 09:08:00 EST
Article-I.D.: umcp-cs.1409
Posted: Wed Nov 28 09:08:00 1984
Date-Received: Fri, 30-Nov-84 07:01:42 EST
References: <85@daemon.UUCP> <33700001@trsvax.UUCP> <2923@allegra.UUCP> <542@godot.UUCP>
Organization: U of Maryland, Computer Science Dept., College Park, MD
Lines: 20
Xref: godot net.bugs.uucp:180 net.bugs.4bsd:616

Actually, there *is* a bug in the 4.2BSD sleep; it's just that the bug
isn't a missing sigsetmask() but two missing calls (sigblock() and
sigsetmask()).  It is *always* *always* *always* a mistake to call
sigpause() to await a signal when the new mask is trying to unblock a
signal that has never been blocked.  (Often it works, but it is still a
mistake.)  The reason is simple: if it's not blocked now, the signal
might happen between the C ``sigpause()'' call and the actual entry
into system code.  System calls are not atomic operations (at user
level) until kernel code is entered; that's *why* sigpause is *defined*
as ``atomically set signal mask and await signal''.

(Gee, maybe we should kludge up the kernel to gripe about sigpause()s
that don't release any signals, giving the name of the offending
program... :-) )
-- 
(This line accidently left nonblank.)

In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (301) 454-7690
UUCP:	{seismo,allegra,brl-bmd}!umcp-cs!chris
CSNet:	chris@umcp-cs		ARPA:	chris@maryland