At 6:01 PM +0200 4/28/05, Ansgar -59cobalt- Wiechers wrote:
On 2005-04-28 Dan Shoop wrote:
> The KILL signal *is* trapped by the process, as it's the process that
implements it's death via the KILL, but the trap prevents any further
process activity other than this signal. A KILL signal is handled
specially by processes under BSD based unices, but it is executed in
its context.
No. SIGKILL means telling the scheduler to terminate a process *here*
and *now*. No cleanup, no nothing. It would be incredibly stupid to
leave it up to the process to handle its own forced termination. I
suppose you're confusing SIGTERM and SIGKILL here.
Of course there's cleanup, otherwise the process table structures
wouldn't get purged properly and the process would still be on the
allproc list. Under unix there is no "scheduler process" and the
responsibility for process creation and death falls to the processes
themselves, executing under the kernel and the BSD subsystem. This is
consistent with most all modern OSen.
It's not "incredibly stupid" to have a process handle it's own
termination, it's incredibly elegant and quite clever. The tome which
describes the internals and operations of BSD, "The Design and
Implementation of the BSD Unix Operating System" has the following to
say about Signals and this process:
"The implementation of signals is broken into two parts: posting a
signal to a process, and recognizing the signal and delivering it to
the target process. Signals may be posted by any process or by code
that executes at interrupt level. Signal delivery normally takes
place within the context of the receiving process."
"The signal handler is a user-mode routine that will invoke when the
signal is received by the process. The handler is said to /catch/ the
signal, which is thus /caught/. Two signals, SIGSTOP and SIGKILL, may
not be ignored or caught; thus restriction ensures that a software
mechanism exists for stopping and killing runaway processes."
It then goes on to talk about how a signal may be either caught,
ignored or blocked (excepting the above) and how signals can be
masked before continuing as relevant to us: "The system does not
allow the SIGKILL, SIGSTOP, or SIGCONT signals to be masked." It also
talks about the signal stack and how signals are push/popped and
masked and processed on the stack and speaks about SIGSTOP/SIGCONT
and its special handling of signals for debugging and then states:
"If the signal is SIGKILL, then the process is set running again no
matter what, so that it can terminate the next time it is scheduled
to run."
Which is quite telling. Basically while SIGKILL is special, in that
it isn't exactly caught in the same way as other signals, it is
'handled' by the process. No 'catch' is necessary, and the signal
isn't stacked.
If you then read the section on process termination this is further
confirmed as it discusses the process terminating itself via exit()
system call or "involuntarily as the result of a [SIGKILL] signal."
"Within the kernel, a process terminates [itself] by calling the
exit() routine. Exit() cleans first cleans up the process's kernel
mode state by (1) Canceling any pending timers (2) releasing any
virtual memory resources (3) closing open descriptors (4) handling
stopped of traced child processes. With the kernel-mode state reset,
the process is removed from the list of processes - the allproc list
..."
Bottom line is that signals are interrupts, and interrupts, of
course, always occur in the context of the process executing them.
Specifically the process receives the SIGKILL signal, unmasked, and
calls exit() through the kernel. This must occur in the process
context. There is no scheduler process for process management and
another process can not perform an exit() on another's behalf.
This is basically the same as it is in all modern OSen. Process
context is responsible for all process action, whether user mode or
kernel mode. The process in this case is running considered to be
running a program of some sort, and the processes job is to support
that. When the program is finished it signals completion to the
process to kill itself, the same mechanism is used when a sigkill is
rcvd. That is the process itself executes the kernel code responsible
for its death.
For a more complete explanation read the entire chapter covering the
above sections, "Process Management".
--
-dhan
------------------------------------------------------------------------
Dan Shoop AIM: iWiring
Systems & Networks Architect http://www.iwiring.net/
email@hidden http://www.ustsvs.com/
AIM: ColonelMode11780
iWiring designs and supports Internet systems and networks based on
Mac OS X, unix, and Open Source application technologies and offers
24x7, guaranteed support to registered clients, at affordable rates.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Macos-x-server mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/macos-x-server/email@hidden
