Exit() system call verses process signals

Hello and thanks in advance for any help anyone can offer me

I've been reading up on process signal calls (sighup, sigint, sigkill & sigterm) and I understand they all have different methods of terminating a running process. From what I've also read is a exit() actually terminates a process.

I'm curious to understand the process Linux goes about to terminating a process with exit() after a process signal has been issued. I've searched google but haven't seen anything that steps thru this. Could someone give me a quick & dirty explanation of this?

Much thanks!

The exit() is called by the process to terminate itself.
The (kill-)signals are sent to a process. A proccess, when it receives a signal, as a default action (defined in libc) terminates (via exit()).
A process can define signal handlers that are invoked when a signal arrives and typically do some cleanup and then often exit().
The signal 9 (SIGKILL) is special: it is not sent to the process but to the kernel; the kernel clears the process memory.

Or to add a little to MadeInGermany's answer -

SIGKILL prevents normal process rundown. It can leave open files in bad condition, for example. You should use it only a last resort when you cannot force a process to exit. In some version of UNIX there are processes you cannot kill.

ps -u in Linux shows a column "stat".

D means the process cannot be killed while in the "D" status.
"Z" gets people upset completely. It means all of the processes' resources except the information kept in the kernel process header are gone. It will NOT do anything except reduce the number of total process slots by one. So if your system is configured for 65535 processes maximum, for example, then you just lost one until the "Z" process goes away. This is the result of poor programming practices - exiting and not waiting for child processes to terminate and be 'reaped'.