Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!mcsun!unido!opal!tmpmbx!scuzzy!src
From: src@scuzzy.in-berlin.de (Heiko Blume)
Newsgroups: comp.unix.programmer
Subject: Re: List of routines safe to use in signals?
Message-ID: <1990Dec20.151909.21631@scuzzy.in-berlin.de>
Date: 20 Dec 90 15:19:09 GMT
References: <RANG.90Dec10231747@nexus.cs.wisc.edu> <1960@necisa.ho.necisa.oz> <59190@brunix.UUCP> <1990Dec12.050527.2152@athena.mit.edu> <1
Organization: Contributed Software
Lines: 85

coren@osf.org (Robert Coren) writes:


>In article <1990Dec18.013608.8234@scuzzy.in-berlin.de>,
>src@scuzzy.in-berlin.de (Heiko Blume) writes:
>|> ...what does sigsuspend(2) *really*
>|> do?

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

seems so. but since interactive (i use that) just puts out the 2.2.1
release with 'posix fixes' (whatever that means), i *hope* that will
be fixed! i'll wait for that before i continue working on this problem.

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

in fact i'm trying to teach bash-1.05 posix job control which of course
catches SIGCHLD etc. i already tried

sigset_t pending,nullmask,savemask;
nullmask = (sigset_t) 0;
sigpending(&pending);
if(pending) {
	sigprocmask(SIG_SETMASK,&nullmask,&savemask);
	/* should get pending signals here ?! */
	sigprocmask(SIG_SETMASK,&savemask,(sigset_t *)0);
}
	/* ugly window for signals to arrive */
else
	sigsuspend(&nullmask);

which is A Real Ugly Thing, and doesn't work all the time anyway.
also, if the process hangs in sigsuspend() i can kill -CLD it as often
as i like, it doesn't unblock.
I wonder how the csh works...

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

ah, that's an argument.

something else i noticed: there's an

int p_chold; /* deferred signal bit mask; sigset(2)
			  * turns these bits on while signal(2)
			  * does not.
			  */

in proc.h. what does that tell me? should i use sigset instead of signal?
or do these bits only get set on sigset(SIGBLA,SIG_HOLD); ???

confused,

	Heiko
-- 
      Heiko Blume <-+-> src@scuzzy.in-berlin.de <-+-> (+49 30) 691 88 93
                    public source archive [HST V.42bis]:
        scuzzy Any ACU,f 38400 6919520 gin:--gin: nuucp sword: nuucp
                     uucp scuzzy!/src/README /your/home