Path: utzoo!censor!geac!torsqnt!news-server.csri.toronto.edu!bonnie.concordia.ca!thunder.mcrcim.mcgill.edu!snorkelwacker.mit.edu!paperboy!think.com!spool.mu.edu!sol.ctr.columbia.edu!samsung!cs.utexas.edu!sun-barr!newstop!exodus!appserv!slovax.Eng.Sun.COM!lm From: lm@slovax.Eng.Sun.COM (Larry McVoy) Newsgroups: comp.unix.internals Subject: Re: SIGCONT occurs after a SIGTERM Message-ID: <455@appserv.Eng.Sun.COM> Date: 20 Feb 91 18:48:46 GMT References: <67880001@hpcupt1.cup.hp.com> <2519@inews.intel.com> <10007@dog.ee.lbl.gov> <2588@inews.intel.com> Sender: news@appserv.Eng.Sun.COM Reply-To: lm@slovax.Eng.Sun.COM (Larry McVoy) Organization: Sun Microsystems, Mt. View, CA. Lines: 17 In article <2588@inews.intel.com> bhoughto@hopi.intel.com (Blair P. Houghton) writes: >In article <10007@dog.ee.lbl.gov> torek@elf.ee.lbl.gov (Chris Torek) writes: >>Signals are not queued. > >Something's stacking them up. > >[description of the delayed receipt of a signal] There is a one deep stack for signals. I think that Chris meant to say that multiple instances of the same signal will all get coalesced into one as long as the signal has not yet been delivered. Think of Unix as a virtual processor, system calls are instructions, and signals are interrupts. In a processor, noone stacks interrupts. The only promise is that one of N will get delivered, N - 1 are all lost. --- Larry McVoy, Sun Microsystems (415) 336-7627 ...!sun!lm or lm@sun.com Brought to you by Super Global Mega Corp .com