Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10 5/3/83; site fortune.UUCP Path: utzoo!linus!philabs!seismo!hao!hplabs!hpda!fortune!berry From: berry@fortune.UUCP Newsgroups: net.bugs.4bsd Subject: Re: Re: sleep() - (nf) Message-ID: <1262@fortune.UUCP> Date: Wed, 13-Jul-83 19:04:01 EDT Article-I.D.: fortune.1262 Posted: Wed Jul 13 19:04:01 1983 Date-Received: Fri, 15-Jul-83 09:46:28 EDT Sender: notes@fortune.UUCP Organization: Fortune Systems, San Carlos, CA Lines: 24 #R:cbosg:-290200:fortune:2000001:000:1011 fortune!berry Jul 13 13:38:00 1983 ***** net.bugs.4bsd / cbosg!dale / 10:11 am Jul 12, 1983 Another possibility we have used for years, is to make pause() return immediately with an error condition if there is no alarm outstanding. This has the disadvantage of not being able to do a pause for another signal unless an alarm is also set, but is not an undue restriction and eliminates all race conditions. ---------- This is all well and good unless the user is not pausing to wait on an alarm signal. If I may quote from the 4.1 manual you will see why this can be a serious concern: Pause never returns normally. It is used to give up control while waiting for a signal from kill(2) or alarm(2). There may be applications (not that I know of any) that are keyboard interrupt driven or use signals such as SIGTINT ("input record available at control terminal.") The latter is probably the more likely occurence of the two, but still the argument stands that pause() is not necessarily used to wait on an outstanding alarm() call.