키보드에서 신호를 수신하는 응용 프로그램은 누가 결정합니까?

터미널에서 키보드의 신호에 대한 나의 현재 이해는 (내 관찰 내용을 Google에서 찾을 수있는 것에 매핑하려는 시도에 주로 근거를두고 있음)입니다.

• 사용자가 Cc를 누름
• 이것은 c의 7 비트 ASCII 값에서 가장 왼쪽의 2 비트를 클리어하여 계산 된 바이트로 터미널의 입력 버퍼에 전송됩니다.

그 후 입력이 무슨 신호를 터미널 (stty)에서 수행 하는지를 의미하기 때문에 안개가 자욱하기 시작합니다. 터미널 자체가 프로세스에 신호를 보내고 있음을 의미한다고 가정합니다. 그러나 나는 또한 그 터미널이 그것을 읽는 응용 프로그램에 대해 알지 못합니다.

터미널에서 키보드로 신호를 보내는 것은 끝에서 끝까지 어떻게 작동합니까?

가압 C하면서 Ctrl가압하는 단말기 에뮬레이터 keyrelease X11 이벤트 뒤에 누르기를 보낸다.

이 이벤트 (일반적으로 키 누르기)에 따라 터미널 에뮬레이터는 ^C의사 -tty 장치의 마스터 측에있는 파일 설명자에 0x3 바이트 ( )를 씁니다 .

isig장치 의 termios 설정이 켜져 있고 intr설정이 0x3 바이트로 설정되어 있으면 커널은 터미널 장치 의 포 그라운드 프로세스 그룹 의 모든 구성원 (pty 장치에 저장된 다른 속성 )으로 SIGINT 신호를 보냅니다 . 이 경우 pty의 슬레이브 쪽에서 0x3 바이트를 읽을 수 없습니다.

일반적으로 setpgid()쉘 작업에 대한 프로세스 그룹 (with )을 작성 하고 포 그라운드로 넣을 ( tcsetpgrp()pty 장치의 해당 속성을 설정 하기 위해) 결정하는 대화식 쉘입니다 .

예를 들어 대화식 쉘 프롬프트에서 실행할 때 :

foo | bar

쉘은 두 개의 과정에 새로운 프로세스 그룹을 시작 (여기서는 실행 foo및 bar파이프와 그 표준 입력 / 출력에 접속 한 후) 및 그 전경 둔다 기이다. Ctrl-C를 누르면 두 프로세스 모두 SIGINT를 수신합니다.

에:

foo | bar &

동일하지만 프로세스 그룹이 포 그라운드로 배치되지 않습니다 (쉘도 대기하지 않으므로 다른 명령을 입력 할 수 있습니다). 이러한 프로세스는 Ctrl-C에서 SIGINT를 얻지 못하지만 tty 장치에서 읽으려고하면 일시 중지 될 수 있습니다.

추가 자료 : 각 PTY (Pseudo-Terminal) 구성 요소 (소프트웨어, 마스터 측, 슬레이브 측)의 책임은 무엇입니까?