Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!yale!umich!terminator!pisa.ifs.umich.edu!rees
From: rees@pisa.ifs.umich.edu (Jim Rees)
Newsgroups: comp.sys.apollo
Subject: Re: signals on domain/os.
Message-ID: <4eb33de3.1bc5b@pisa.ifs.umich.edu>
Date: 20 Dec 90 03:12:06 GMT
References: <4eb271297.000f088@caen.engin.umich.edu>
Sender: usenet@terminator.cc.umich.edu (usenet news)
Reply-To: rees@citi.umich.edu (Jim Rees)
Organization: University of Michigan IFS Project
Lines: 29

In article <4eb271297.000f088@caen.engin.umich.edu>, paul@CAEN.ENGIN.UMICH.EDU (Paul Killey) writes:
  
  This is my latest discovery in comparative signalology.

I'm glad to see that my esteemed colleague is still keeping us on our toes.
Too bad I can't wangle an all-expenses-paid trip to fix this like in the old
days, eh Paul?

The sigpause() always returns on receipt of ignored signals.  The manual is
somewhat evasive on the subject of whether this should be the case or not. 
It says that it "waits for a signal to arrive," but doesn't say anything
about whether it has to be a signal that actually does anything or not.
I suppose it depends on your definition of "ignore."  I can ignore my neighbor
when she plays her stereo too loud, but does that mean I don't hear Def
Lepperd thundering through the floor?  Of course I do.

I would take this to mean that sigpause should return on receipt of any
signal, which is just what it does (not surprising, since I wrote the bsd4.2
signal stuff for sr9.  And a hairy mess it was, too.  Job security, you
know.)

But a glance at the Berkeley code, and experiment (as Paul has shown)
demonstrate that the sigpause shouldn't return on ignored signals.  Maybe
you should file an APR.

Of course, any well-written program will put the sigpause in a loop and test
for whether the condition it is waiting on has become true before breaking
out of the loop, so this slight signal-semantics slip-up is simply
superfluous.  Don't tell me, sendmail depends on this behavior...