09-20-05 12:49 PM
rahul8143@gmail.com writes:
> Rich Gibbs wrote:
> Its not a homework question. i am learning on my own. and what i
> learnt is that SIGINT is used to send ctrl+c interrupt signal to
> currently running program. and SIGTERM is used for termination of the
> process then whats is difference between them?
It works this way:
The terminal is configured with stty.
(type: man 1 stty
stty -a
for example, the following characters are configured here:
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W;
lnext = ^V; flush = ^O;)
When you type the character that is configured for intr, the terminal
driver sends the SIGINT signal to the process attached to the terminal.
If you type the character configued for quit, it sends the SIGQUIT
signal.
And for the character configured for susp, it sends the SIGSTOP signal
(which suspends the process, to be resumed when it receives SIGCONT).
Then you need to read signal(7) to know what happens when a process
receives a signal. Type: man 7 signal
This manual page indicates for each signal the default action.
The default action for Both SIGINT and SIGTERM is to terminate the process.
But as you've seen when you've read man 1 stty, the terminal can only
send a SIGINT, not a SIGTERM signal.
Note that all signals but SIGKILL can be ignored or handled. Some
programs are designed not to terminate when they receive the SIGINT
signal, but merely to terminate the current action and revert to the
main menu for example.
The SIGKILL signal cannot be ignored and provoke the immediate
termination of the process by the OS. The process can still linger if
it's waiting in the kernel for I/O to complete, but it is killed
immediately.
So you've got these three level of interruption:
SIGINT: stop the current activity and wait for new user input.
SIGTERM: terminate the program, closing cleanly the files, network
connections, databases, etc.
SIGKILL: forcibly kill a process without leaving it a chance to clean up.
The exact difference between two signals (apart from SIGKILL and
SIGSTOP/SIGCONT), depends actually on the signal handler installed by
the program, or the default. A lot of program install the same signal
handler on both, so there's no difference for these programs.
> And when proess receive signal i know that its control
> transferred from currently running process to signal handler thats it
> but then what? what about that process's memory data,registers are they
> saved or not? does context switch occurs or not? signal handler
> executes in user space isn't it?
The signal handler is but a function in the process. There is no
context switch. The signal handler works in the same virtual memory
space as the process: it's a simple function inside the process.
As with any other function call the signal handling code stacks the
registers, and restore them on return.
The only difference between the invocation of a signal handler
function and that of the other functions of the program, is that in
the case of the signal handler, there's no call in the program: the
signal handler function can be "called" virtually from any point in
the program.
If you want to know all the details, the best is to read the sources
of some unix (eg. linux or freebsd); start with the kill(2) syscall.
--
__Pascal Bourguignon__ http://www.informatimago.com/
Nobody can fix the economy. Nobody can be trusted with their finger
on the button. Nobody's perfect. VOTE FOR NOBODY.
[ Post a follow-up to this message ]
| 
