killing processes

[R.HUTCHISON]

First, I assume you are talking about system V.  If not, my comments
may not apply......

In article <11372 at mimsy.UUCP>, chris at mimsy.UUCP (Chris Torek) writes:
] In article <13282 at brl-adm.ARPA> rbj at icst-cmr.arpa (Root Boy Jim) writes:
] >I believe that killing a process merely sets a bit in its signal mask, which
] >is not looked at until the affected process is rescheduled.
] 
] It does a bit more.  If the affected process is sleeping interruptably,
] it is made runnable and has its priority raised to PUSER if it is now
] lower.  If it is actively running, its killing itself arranges for an
] `AST' (no not the Minix AST :-) ) so that it will be sure to see the
] signal.

On system V, if the process is sleeping interruptably its priority is
between 25 and 39.  When the signal is sent, the sending routine posts
the signal (sets the bit) and reawakens the sleeping process.  The
process retains its priority and makes it a good candidate to run
soon.  If the process is runnable (perhaps in an infinite loop), the
signal will be posted to the process and it will be recognized by the
process after it is switched in.  Signals, for runnable processes, are
checked after a switch-in immediately following a pre-emption.

By the way, I've heard these interruptable (bad word) processes called
"sleeping uglies" while processes that are sleeping with a priority
less than 25 (PZERO) are called "sleeping beauties."  How common are
these terms?

] 
] In other words, the affected process is arranged to be run soon, so that
] the signal will happen.
] -- 
] In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
] Domain:	chris at mimsy.umd.edu	Path:	uunet!mimsy!chris


Bob Hutchison
lzaz!hutch