SIGCONT occurs after a SIGTERM

[Edward Conger]

/ hpcupt1:comp.unix.wizards / coleman at cam.nist.gov (Sean Sheridan Coleman X5672) /  9:06 am  Feb 11, 1991 /
>Please explain to me why a SIGCONT is sent to a process after
>SIGTERM is sent to my process. It doesn't compute because TERM
>means to terminate the the process.

The distinction is that sending a signal to a process (usually|often)
is implemented by setting a bit in a flag word associated with the
"victim process".  The action of *send*ing the signal doesn't 
terminate the process, rather, it says, "when next you run in the
kernel (either via a system call or a timeslice (usually ~ 1/100 sec)),
you should go handle this signal."  In the case of SIGTERM, the default
behaviour is to TERMinate.

Now suppose the victim process is stopped (either by job control, SIGSTOP,
or via debugging), it will NOT see the bit set in the flag word until it
runs again.  The SIGCONT gets it unstopped and it runs long enough to
terminate.

Your mileage (and implementation) may vary, but this is the general gist of
the problem.

>Thanks

>Sean Coleman
>coleman at bldrdoc.gov
>NIST
>Boulder, CO
>----------

Hope this helps,

-Ed.

===========================================================================
The above is an official statement of MeMyself & I Inc.  It should not
be interpreted to be an official statement of any other likely targets,
including, but not limited to, Hewlett-Packard Co., ACME Rockets, ACME Rubber
Bands, ACME Consolidated Mining Engineering, or the Home for Damaged Coyotes.