How does the kill command work? How does it communicate to a process that it should die, etc...? Through a pipe? file? I am having trouble finding an answer to this.
You're right PHV (as usual ). It's a signal(3C) call.
I've always hated that the command line utility to send signals to a process was called [tt]kill[/tt] because signals are used for a lot more than killing processes. It's a misnomer in my opinion.
A signal is a kind of software interrupt that's sent to the process. Kind of a tap-on-the-shoulder from the OS. The process can either handle the signal by jumping to some code that deals with it, or not. If a process is not programmed to handle a signal, the signal will usually cause the process to terminate. The programmer of the process can write handler routines to deal with or ignore every signal except for 9, SIGKILL. This is the only signal that can't be caught and will kill all processes (unless something's really messed up).
The function [tt]sigaction[/tt] (man sigaction) lets you define functions that your code will jump to to handle whatever signals your code receives. This lets you "trap" those signals and allows your to do something smart and controlled, instead of just dieing. This is usefull to have a program shut down cleanly and properly close files instead of just aborting and leaving a mess.
See the man pages for [tt]signal[/tt] and [tt]sigaction[/tt]. There are a lot of good links with info on signals. Here's on from a quick Google...
Strictly speaking it's an exception that causes a Trap.
There are two kinds of interupts Hardware and Software. When an intrupt or trap hapens (like, "A key is pressed" the kernel is envoked (unless it has the generated exception masked) and passes information about the interupt on to the program. That is why all I/O is done with library functions that wrap system calls. The program has no idea what a disk is, how to access it and if it could access it without going through the kernel there would be huge security and consistency problems...
Programs can decide what to do on certian interupts, based on the information the kernel sends back. Others, the kernel performs some basic action and the program doesn't need to know anything happened.
Also important to mention is that certian signals cause re-enterent interupts, while others generate non-re-enterent interupts. Meaning that an interupt can be interupted... Which is sometimes good to use. If something happens and a program freezes, and you 'kill' it, the program can begin to do the kill code -- and then lets say that the errors are too great it freezes agian, it might be written that a second "kill" will terminate the program without any attempt to clean up. Also, this is why some programs can't be "ctrl+c"'d -- like most versions of vi -- they handle the signal generated by ctrl-c to mean something other than "die now!!!!".
I hope that wasn't as rambling as I think it was, and that it is what you were looking for.
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.