From the 4BSD manual for csh:
A ^Z takes effect immediately and is like an interrupt in that pending output and unread input are discarded when it is typed. There is another special key ^Y which does not generate a STOP signal until a program attempts to read(2) it. This can usefully be typed ahead when you have prepared some commands for a job which you wish to stop after it has read them.
So, the purpose is to type multiple inputs while the first one is being processed, and have the job stop after they are done.
Your understanding so far is correct, but you miss most of the complexity that's built on that. The processing in the kernel happens in several layers, and the keypress "bubbles up" through the layers.
The USB communication protocol itself is a lot more involved. The interrupt handler routine for USB handles this, and assembles a complete USB packet from multiple fragments, if necessary.
The key press uses the so-called HID ("Human interface device") protocol, which is built on top of USB. So the lower USB kernel layer detects that the complete message is a USB HID event, and passes it to the HID layer in the kernel.
The HID layer interprets this event according to the HID descriptor it has required from the device on initialization. It then passes the events to the input layer. A single HID event can generate multiple key press events.
The input layer uses kernel keyboard layout tables to map the scan code (position of the key on the keyboard) to a key code (like A) and interprets Shift, Alt, etc. The result of this interpretation is made available via /dev/input/event* to userland processes. You can use evtest to watch those events in real-time.
But processing is not finished here. The X Server (responsible for graphics) has a generic evdev driver that reads events from /dev/input/event* devices, and then maps them again according to a second set of keyboard layout tables (you can see those partly with xmodmap and fully via the XKBD extension). This is because the X server predates the kernel input layer, and in earlier times had drivers to handle mouse and PS/2 keys directly.
Then the X server sends a message to the X client (application) containing the keyboard event. You can see those messages with the xev application. LibreOffice will process this event directly, VIM will be running in an xterm which will process the event, and (you guessed it) again add some extra processing to it, and finally pass it to VIM via stdin.
Complicated enough?
Best Answer
Ctrl+C (control character
intr): It will sendSIGINTsignal to a process and usually application gets abort but the application can handle this signal. For example you can handle a signal withsignal()function inCLanguage.Ctrl+Z (control character
susp): It will sendSIGTSTPsignal to a process to put it in background and likeSIGINTit can be handle.The process will not kill immediately with Ctrl+C if it has wait I/O and you have to wait to finish its I/O and then the application will terminate from memory.
But Ctrl+Z will pause your process and its I/Os. Technically the operating system will not give it CPU time and if you kill the background process, it may lose some I/O and data.
For force killing a process you have to
SIGKILLor signal number 9 which is most powerful signal - the operating system will kill it immediately, but you may lose data, as the program will have no way to react to this signal.