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