sleep() - (nf)

[berry at fortune.UUCP]

#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.