dale@cbosg.UUCP (07/12/83)
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.
berry@fortune.UUCP (07/14/83)
#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.guy@rlgvax.UUCP (Guy Harris) (07/17/83)
Having pause() only work if there is an alarm outstanding works if 1) you
have some other way to implement a block/wakeup mechanism (using pause(),
signal(), and kill() for this is a ghastly kludge but if it's all you've got...)
as USG UNIX 5.0 does, I believe 4.2BSD does (I don't have my 4.2BSD System
Manual handy), and I suspect CB-UNIX does, or 2) every time a process does
a block explicitly requested as such by user-mode code it wants a timeout.
Guy Harris
{seismo,mcnc,we13,brl-bmd,allegra}!rglvax!guyguy@rlgvax.UUCP (Guy Harris) (07/18/83)
In a previous note I mentioned that if several processes are sleeping on
a pause(), and one of them gets an alarm(), all of them get woken up. It
turns out that the problem is that in vanilla V7 psignal() uses wakeup() to
wake the recipient up. This means that if more than one process is in a
pause() and sleeping on &u (which is the same address for all processes on
most systems), if one process gets signalled out of the sleep all the other
processes will wake up. However, on 4.1BSD and System III, it looks like
this isn't a problem because on those systems psignal() doesn't use wakeup()
to make the target process runnable, but moves the process to the run queue
and changes its state directly. We encountered the problem on a V7-based
kernel.
Guy Harris
{seismo,mcnc,we13,brl-bmd,allegra}!rlgvax!guy