Path: utzoo!mnetor!tmsoft!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!samsung!think.com!paperboy!speed.osf.org!coren
From: coren@osf.org (Robert Coren)
Newsgroups: comp.unix.programmer
Subject: Re: List of routines safe to use in signals?
Message-ID: <17385@paperboy.OSF.ORG>
Date: 18 Dec 90 14:59:53 GMT
References: <RANG.90Dec10231747@nexus.cs.wisc.edu> <1960@necisa.ho.necisa.oz> <59190@brunix.UUCP> <1990Dec12.050527.2152@athena.mit.edu> <1 <1990Dec18.013608.8234@scuzzy.in-berlin.de>
Sender: news@OSF.ORG
Reply-To: coren@osf.org (Robert Coren)
Organization: Open Software Foundation, Cambridge, Massachusetts
Lines: 45


In article <1990Dec18.013608.8234@scuzzy.in-berlin.de>,
src@scuzzy.in-berlin.de (Heiko Blume) writes:
|> ...what does sigsuspend(2) *really*
|> do? say, i block SIGCHLD. A child dies. The signal get's posted
|> to the parent. since it's blocked it's "pending". ok, what happens when
|> i call sigsuspend() then, with a mask all zeroes. the man page says it
|> suspends the process until the *delivery* of a signal not masked by
|> sigsuspend()'s argument. guess what, although the signal is pending,
|> the process gets blocked! WHY? [anyway, i'll elaborate on this in
|> another posting due soon...]

The specification of sigsuspend()'s behavior with respect to signals
that are *already* pending when a program calls sigsuspend() do seem
to be a little vague. I don't have POSIX 1003.1 handy at the moment,
but I took a look at the OSF/1 manpage, and it seems to contain at
least an implication that such a signal is delivered when you call
sigsuspend() (assuming the mask specified in sigsuspend() unmasks the
pending signal). I also took a quick look at the OSF/1 *code*, and
this is in fact what it does.

It may be that your system's implementation interpreted the spec for
sigsuspend()) differently, or it may just be wrong.

Another possibility (admittedly remote) comes to mind. I would assume
that you have set up a handler for SIGCHLD, since you seem to be
interested in its delivery. Is this in fact the case? Have you
confirmed that the SIGCHLD signal is in fact pending (try using
sigpending())? The reason I ask this is that the default behavior for
SIGCHLD is SIG_IGN, in which case it would have vanished silently when
it was posted.

|> ...as far as i get it,
|> the BSD sigpause(2) is equivalent to posix sigsuspend(2), so what
|> has sigpause(2) to do in a posix environment anyway?

A system that implements sigsuspend() maintains sigpause() for
compatibility with "older" systems; they are essentially equivalent. A
potential difference is that the mask given to sigpause() is an int,
where as that given to sigsuspend() is a sigset_t; a system that
implements more than 32 signals (as AIX does, I believe) can define
sigset_t in such a way that sigsuspend() can mask any combination of
signals, but sigpause() can only mask signals with numbers in the
range 1 <= s <= 32.
	Robert