Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!wuarchive!mit-eddie!uw-beaver!milton!ogicse!intelhf!ichips!inews!hopi!bhoughto
From: bhoughto@hopi.intel.com (Blair P. Houghton)
Newsgroups: comp.unix.wizards
Subject: Re: SIGCONT occurs after a SIGTERM
Message-ID: <2588@inews.intel.com>
Date: 19 Feb 91 04:42:47 GMT
References: <67880001@hpcupt1.cup.hp.com> <2519@inews.intel.com> <10007@dog.ee.lbl.gov>
Sender: news@inews.intel.com
Organization: Intel Corp, Chandler, AZ
Lines: 25

In article <10007@dog.ee.lbl.gov> torek@elf.ee.lbl.gov (Chris Torek) writes:
>In article <2519@inews.intel.com> bhoughto@pima.intel.com
>(Blair P. Houghton) writes:
>>Not the least of those variances is that signals may be queued ....
>
>Signals are not queued.

Something's stacking them up.

I've run into situations more than once where I've tried to
stop a process and the stop has hung, usually due to
something else's being stuck (an NFS access, e.g.) I've
sent the stop again, and when the block clears I see the
process stop.  When I tell the process to continue, the
first thing it does is stop itself again.

Who's doing it?  The kernel or csh(1)?  The tty driver?  Or
is it just a matter of a stuck process queue?  I can't
imagine all the kills not being done by the time I've typed
in the command to continue...

				--Blair
				  "It also happens under VMS,
				   but I'll keep mention of that
				   'Fine' system to a minimum..."