프로그램 실행 중 사용자가 Ctrl+C를 누르거나, 프로세스가 허가되지 않은 메모리 영역을 건드렸을 때, 프로세스는 이 사실을 어떻게 알아챌까요? 커널이 이러한 '위기 상황'을 프로세스에게 통보하는 수단, 그것이 바로 시그널입니다.

시그널은 군더더기 없는 초단문 메시지입니다. 일반적인 편지처럼 구체적인 내용을 싣지 않고, 대개 "몇 번 시그널인가"라는 번호 하나만으로 그 의미를 전달합니다. 예컨대 SIGINT는 키보드 인터럽트를, SIGSEGV는 잘못된 메모리 접근을, SIGCHLD는 자식 프로세스의 상태 변화를 부모에게 알리는 신호로 쓰입니다.

이 장을 관통하는 핵심 주제는 세 가지입니다. 첫째, 시그널의 존재 이유 — 시스템 이벤트나 프로세스 간의 통신을 알리기 위함입니다. 둘째, 생성과 전달의 원리 — 커널은 우선 "해당 프로세스에 시그널이 대기 중(pending)이다"라고 기록해 두고, 이후 적절한 타이밍에 이를 전달합니다. 셋째, 프로세스의 대응 방식 — 시그널을 무시할 수도, 커널의 기본 동작에 따를 수도, 혹은 직접 작성한 signal handler를 통해 대응할 수도 있습니다.

지금부터 우리는 시그널을 단순히 "프로세스를 강제로 죽이는 명령"으로 치부하지 않고, 커널과 프로세스 사이를 잇는 정교한 이벤트 전달 메커니즘으로 바라볼 것입니다.

시그널의 목적은 명확합니다. 프로세스에게 특정 사건의 발생을 알리고, 그에 대응하는 함수(signal handler)를 실행하도록 유도하는 것입니다.

예컨대 키보드에서 Ctrl+C를 누르면 SIGINT가 발생하고, 이 시그널의 기본 동작은 프로세스 '종료'입니다. 하지만 프로그램이 미리 핸들러를 등록해 두었다면, 무작정 종료되는 대신 "열려있던 파일을 안전하게 저장하고 닫기" 같은 사용자 맞춤형 종료 절차를 밟을 수도 있습니다.

Terminate와 Dump는 '프로세스를 죽인다'는 결론은 같지만, Dump만 core file을 남길 기회를 제공한다는 점이 다릅니다. Stop은 강제 종료가 아닌 일시 정지 상태로 만들고, Continue는 그 정지 상태를 풀어 다시 달리게 하며, Ignore는 보고는 받되 신경 쓰지 않는 조치입니다.

리눅스 환경에서 1번부터 31번까지는 일반적인 regular signal(표준 시그널)로 분류되고, 32번부터 64번까지는 real-time signal로 다뤄집니다. real-time signal의 가장 큰 무기는 바로 '큐잉(Queueing)'입니다. 만약 SIGUSR1이 10번 연속 쏟아질 때 아직 프로세스가 이를 전달받지 못한 상황이라면, 표준 시그널은 단 한 번만 온 것처럼 pending 표시를 남기지만, real-time signal은 10번의 발생 기록을 모두 고스란히 보존해 줍니다.

프로세스가 시그널에 대처하는 방식은 크게 세 갈래로 나뉩니다. 명시적으로 무시(ignore)해버리거나, 커널이 미리 정해둔 기본 동작을 묵묵히 따르거나, 직접 시그널 핸들러를 등록해 상황을 통제(catch)하는 것입니다.

하지만 이 규칙에도 절대적인 예외가 존재합니다. 바로 SIGKILL과 SIGSTOP입니다. 이 두 시그널은 결코 무시할 수도, 핸들러로 잡아낼 수도, 차단할 수도 없습니다. 운영체제 입장에서 폭주하는 프로세스를 제어할 최후의 보루가 필요하기 때문입니다. 만약 악의적인 목적을 가졌거나 치명적인 버그가 있는 프로세스가 모든 시그널을 틀어막아버린다면, 시스템 관리자는 이 두 시그널을 통해서만 상황을 통제할 수 있습니다.

요약하자면, Ignore는 시그널을 받긴 했으나 무대응으로 일관하는 것, Block은 아예 수신 자체를 뒤로 미루는 것, Catch는 준비된 핸들러를 가동하는 것입니다. 그리고 SIGKILL과 SIGSTOP은 이러한 모든 방어막을 무력화하는 커널의 절대 반지와 같습니다.

POSIX 멀티스레드 환경에서 우리가 흔히 '단일 프로세스'라고 뭉뚱그려 부르는 것은, 실질적으로 여러 경량 프로세스(LWP), 즉 스레드들이 옹기종기 모인 스레드 그룹(thread group)을 의미합니다.

이러한 구조 탓에 대기 중인 시그널(pending signal)도 두 종류로 나뉩니다. 특정 스레드를 콕 집어 보낸 것은 private pending signal, 그룹 전체의 우편함에 꽂힌 것은 shared pending signal입니다. 요약하자면 멀티스레드의 시그널 규칙은 "정책은 다 같이, 마스크는 각자, 그룹 시그널 처리는 대표 한 명, 그러나 사형 선고(fatal)는 연대 책임"입니다.

어떤 시그널이 대기 중(pending)인지, 혹은 차단(block)되었는지 등의 상태 정보는 커널의 프로세스 디스크립터와 그 주변 자료구조에 꼼꼼히 기록됩니다. 이 네트워크의 중심에는 task_struct가 자리 잡고 있으며, 여기서 signal, sighand, pending, blocked 같은 주요 필드들이 파생됩니다.

마스크를 표현하는 sigset_t는 두 개의 32비트 unsigned long 배열로 짜여 있어, 도합 64비트의 공간을 제공합니다. 리눅스의 최대 시그널 개수(_NSIG)가 64개이기 때문입니다. 재밌는 점은 시그널 번호 0번은 존재하지 않으므로, 1번 시그널이 비트 인덱스 0번에, 64번 시그널이 비트 인덱스 63번에 매칭된다는 사실입니다.

멀티스레드 애플리케이션에서는 같은 스레드 그룹에 속한 녀석들끼리 signal_struct와 sighand_struct를 공유합니다. 대응 매뉴얼(정책)은 공유하되, 각 스레드의 blocked와 pending은 독립적으로 가져가는 것—이 절묘한 균형 감각이 바로 POSIX 표준을 완벽히 소화해 내는 리눅스 커널의 핵심 설계 철학입니다.

k_sigaction은 사용자 모드에 노출되는 sigaction 구조체에 커널의 은밀한 제어 정보가 덧붙여진 구조입니다. 이 구조체를 지탱하는 3대 기둥은 sa_handler, sa_flags, 그리고 sa_mask입니다.

대기 중인 시그널이 머무는 큐(pending signal queue) 역시 두 곳입니다. 그룹용 shared pending queue와 개인용 private pending queue죠. 이 둘은 모두 sigpending이라는 구조체로 표현되는데, 여기에는 "어떤 번호의 시그널이 대기 중인가?"를 단번에 알려주는 비트 마스크인 signal과, 시그널이 발생한 구체적 정황들을 줄줄이 엮어놓은 sigqueue 연결 리스트(list)가 공존합니다.

그 연결 리스트의 핵심 요소인 sigqueue 내부에는 siginfo_t info가 똬리를 틀고 있습니다. siginfo_t는 특정 시그널 발생 사건을 파헤치는 128바이트짜리 조서와 같습니다. 여기에는 si_signo(어떤 시그널인가), si_errno(연관된 오류 코드), si_code(도대체 누가, 왜 이 시그널을 유발했는가)가 상세히 적힙니다.

_sifields 영역은 시그널의 성격에 따라 카멜레온처럼 모습을 바꿉니다. SIGKILL이라면 발신자의 PID와 UID를 적어두고, SIGSEGV라면 프로세스가 무단 침입하려 했던 사고 현장(메모리 주소)을 꼼꼼히 기록합니다. 다만 일반적인 표준 시그널은 이런 복잡한 정보 없이 쿨하게 번호 하나만으로 소통하는 것이 기본 모델입니다.

시그널의 존재 여부를 따지는 작업은 대부분 비트 마스크(bit mask)를 통해 눈부신 속도로 처리됩니다. 시그널 번호를 특정 비트 위치로 치환한 뒤, 그 비트의 전원을 켜면(1) "포함", 끄면(0) "제외"가 되는 아주 명쾌한 논리입니다.

내부적인 비트 매핑 공식을 들여다보면, (nsig - 1) / 32 연산을 통해 두 개의 배열 중 어느 쪽에 속하는지 찾고, (nsig - 1) % 32 연산으로 그 안에서 몇 번째 자리인지 정확히 타격합니다. 시그널 번호가 1번부터 시작하기 때문에 nsig - 1로 영점 조정을 하는 것이 포인트입니다.

단순한 연산을 넘어 시그널 전달의 방아쇠 역할을 하는 함수들도 있습니다. signal_pending(p) 함수는 특정 프로세스에게 '차단되지 않은(nonblocked) 대기 시그널'이 단 하나라도 있는지를 감식해 냅니다. 이 함수는 곧 TIF_SIGPENDING 플래그를 검사하는 것인데, 이 플래그가 켜져 있다는 것은 "사용자 모드로 돌아가기 전에 무조건 시그널 처리부터 마무리하라!"는 커널의 엄명과 같습니다.

큐에서 시그널을 덜어내는 rm_from_queue(mask, q), 큐 전체를 깔끔하게 비우는 flush_sigqueue(q), 나아가 개인/공용 큐를 모조리 청소하고 TIF_SIGPENDING까지 초기화하는 flush_signals(t)까지. 복잡해 보이지만 본질은 하나입니다. 빠른 유무 판단은 비트 마스크에게 맡기고, 디테일한 정보는 연결 리스트에 위임하는 분업의 미학입니다.

단일 프로세스를 향한 시그널 전송 흐름은 궁극적으로 specific_send_sig_info(sig, info, t) 함수로 수렴합니다. 이때 info 인자가 재미있는데, 값이 0이면 일반 사용자가 보낸 것이고, 1이면 커널이 보낸 것이며, 2라면 커널이 작정하고 보낸 SIGSTOP/SIGKILL 류의 통제 불능 시그널임을 뜻합니다.

결론적으로 '생성' 단계의 역할은 "대기(pending) 상태를 장부에 적고, 잠든 수신자를 흔들어 깨우는 것"까지입니다. 아직 핸들러가 출동하기 전입니다.

스레드 그룹 전체를 대상으로 하는 시그널 전송은 group_send_sig_info(sig, info, p) 함수가 담당합니다. 함수가 호출되면 가장 먼저 시그널 번호가 합당한지 따져보고, 유저 모드에서 날아온 시그널이라면 깐깐한 권한 심사를 거칩니다. 발신자가 충분한 capability를 쥐고 있는지, SIGCONT를 같은 세션 내에서 보냈는지, 혹은 발신자와 수신자의 계정이 일치하는지 확인합니다. 자격 미달이라면 가차 없이 -EPERM 에러를 뱉어냅니다.

여기서 흥미로운 관전 포인트는 시그널 번호(sig)가 0일 때입니다. 0번 시그널은 실제 통신용이 아니라, "내가 이 대상에게 시그널을 보낼 수 있는 권한이 있나?"를 조용히 찔러보는(probe) 용도로 쓰입니다.

심사를 무사히 통과하면 해당 시그널은 무시 대상이 아닌지, 표준 시그널이 중복 수신된 것은 아닌지 한 번 더 확인한 후 send_signal()을 통해 그룹 공용 큐(shared pending queue)에 사뿐히 안착합니다. 그다음, __group_complete_signal() 함수가 출동해 그룹 내 여러 스레드 중 누가 총대를 멜지 적임자를 물색합니다.

만약 도착한 시그널이 fatal signal이라면 적임자를 고를 여유도 없이 그룹 전체에 SIGKILL을 뿌려 다 같이 동반 종료시킵니다. fatal이 아니라면 마침내 선택받은 단 한 명의 스레드에게 signal_wake_up() 기상 나팔을 울려 처리할 업무가 생겼음을 알립니다.

커널은 시스템 콜이나 인터럽트 처리를 마치고 사용자 모드로 복귀하기 직전, 항상 현재 프로세스의 TIF_SIGPENDING 플래그를 점검합니다. 이 깃발이 펄럭이고 있다면 주저 없이 do_signal() 함수를 호출합니다. 시그널 핸들러는 철저히 사용자 모드에서 도는 코드이므로, 커널 입장에선 "유저 모드로 돌아갈 때 슬쩍 실행 흐름을 꺾어버리는" 이 타이밍이 기가 막히게 적절한 것입니다.

관문 역할을 하는 do_signal(regs, oldset)은 두 개의 티켓을 검사합니다. regs는 유저 모드에서 쓰던 레지스터 값들이 커널 스택에 곱게 보관된 주소이고, oldset은 원래 프로세스가 쓰던 차단 마스크(blocked signal mask) 주소입니다. 만약 시스템이 인터럽트를 처리하다가 커널 모드로 돌아가는 중이었다면(유저 모드 복귀가 아니라면), 시그널 처리를 나중으로 미루고 재빨리 함수를 빠져나갑니다.

만약 프로세스가 디버깅(tracing)을 당하고 있는 중이라면, 시그널을 전달하는 이 찰나의 순간에 커널은 디버거 프로세스에게 귓속말(알림)을 보내고 스케줄러를 호출해 제어권을 넘깁니다. 우리가 GDB 같은 툴로 프로세스의 숨통을 쥐었다 폈다 하며 변수를 뜯어볼 수 있는 마법의 비밀이 바로 여기에 숨어 있습니다.

시그널 핸들러가 SIG_DFL로 설정된 경우, do_signal()은 커널에 굳건히 정의된 기본 동작을 수행합니다. 여기서 가장 흥미로운 예외 대상은 다름 아닌 PID 1번, 바로 init 프로세스입니다. 시스템의 뿌리인 init 프로세스에게 날아간 시그널은 핸들러로 낚아채지 않는 이상 커널이 조용히 씹어버립니다(버려집니다).

태생 자체가 무시(ignore)가 기본인 시그널들(SIGCONT, SIGCHLD, SIGWINCH, SIGURG)은 말 그대로 가볍게 무시된 채 루프는 다음 대기 시그널을 향해 넘어갑니다.

반면 멈춤(stop)이 기본 동작인 시그널(SIGSTOP, SIGTSTP, SIGTTIN, SIGTTOU)은 스레드 그룹 전체의 시간을 멈춰 세웁니다. 단, 무적의 SIGSTOP을 제외한 나머지 정지 시그널들은 orphaned process group 상태일 때 POSIX 규칙에 따라 종종 무시되기도 합니다. 여기서 고아 프로세스 그룹이란 단순히 부모가 죽어버렸다는 뜻이 아니라, 같은 세션 내의 다른 프로세스 그룹에 속해 있으면서 든든한 뒷배가 되어줄 부모 프로세스가 더 이상 존재하지 않는 고립된 상태를 뜻합니다.

기본 동작이 덤프(dump)인 시그널은 프로그램의 뼈와 살이 분리되는 순간을 찰칵 찍어 디버깅용 core file로 남겨주는 친절함을 발휘합니다. 이 코어 파일 안에는 프로세스의 메모리 상태와 CPU 레지스터 값들이 고스란히 얼어붙어 있습니다. 유언장을 남긴 프로세스는 곧바로 죽음을 맞이합니다. 나머지 무자비한 강제 종료(terminate) 시그널들은 do_group_exit()을 호출해 스레드 그룹 전체의 숨통을 일거에 끊어버립니다. 멀티스레드 환경에서는 나 하나 잘못해서 프로그램 전체가 셧다운되는 연대 책임의 무서움을 엿볼 수 있습니다.

시그널을 '잡는다(catch)'는 것은 단순히 등록된 함수 포인터를 띡 하고 호출하는 수준의 간단한 작업이 아닙니다. 시그널 핸들러는 철저히 사용자 모드 영역의 코드인데, 지금 이를 통제하고 있는 커널은 커널 모드에 머물러 있습니다. 따라서 커널은 "프로세스가 유저 모드로 눈을 떴을 때, 원래 실행하려던 코드 대신 핸들러 함수 첫 줄에 서 있게끔" 실행 문맥(context)을 정교하게 속여야 합니다.

왜 굳이 사용자 모드 스택에 프레임을 쌓아야 할까요? 핸들러 실행이 끝난 후 프로세스가 원래 돌던 곳으로 돌아가려면, 사고가 터지기 직전의 레지스터 상태를 어딘가에 잘 보관해 두어야 합니다. 그런데 커널 스택은 유저-커널을 오갈 때마다 포맷되고 재사용되는 험악한 동네라, 커널은 이 귀중한 백업 데이터를 안전한 사용자 스택 영역에 고스란히 복사해 두는 것입니다.

handle_signal()은 SA_SIGINFO 플래그의 유무를 보고 무대를 고릅니다. 복잡한 사건 조서가 필요 없으면 setup_frame()으로 기본 프레임을 깔고, 상세한 siginfo_t가 필요하면 덩치가 큰 확장 프레임을 짜는 setup_rt_frame()을 호출합니다.

프레임을 완성한 커널은 마지막으로 커널 스택에 잠들어있는 프로세스의 레지스터 복사본(regs)을 손봅니다. 스택 포인터(esp)는 방금 만든 프레임을 가리키게 꺾고, 명령어 포인터(eip)는 핸들러의 첫 주소를 정조준하며, eax 레지스터엔 시그널 번호를 살포시 얹습니다. 이로써 프로세스가 눈을 뜨는 순간(유저 모드 복귀), 완전히 새로운 연극이 시작되는 것입니다.

시그널 핸들러가 한창 실행 중일 때, 얄궂게도 동일한 시그널이 또 발생하면 어떻게 될까요? 기본적으로 커널은 현재 처리 중인 시그널이 핸들러 실행 동안 다시 끼어들지 못하도록 꽉 틀어막습니다(block). 이렇게 해주지 않으면 핸들러 코드는 재진입(re-entrant) 상황을 완벽하게 대비해야 하고, 개발자들의 디버깅 지옥 문이 열리게 됩니다.

handle_signal()은 프레임을 세팅한 직후 sa_flags를 쓱 훑어봅니다. 만약 SA_NODEFER 깃발이 없다면, 커널은 sa_mask에 명시된 시그널들을 차단 목록(blocked)에 올리고 방금 터진 시그널 자신도 차단 명단에 얹은 뒤 recalc_sigpending()을 호출해 상황을 갱신합니다. 반대로 SA_NODEFER가 펄럭인다면, 커널은 "그래, 방해받든 말든 네 마음대로 해라"라며 자동 차단막을 내려주지 않습니다.

만약 SA_SIGINFO 플래그를 달아 확장 프레임으로 놀았다면, 복귀 경로도 __kernel_rt_sigreturn을 거쳐 rt_sigreturn() 시스템 콜을 타게 되지만 전체적인 그림은 다르지 않습니다.

여기서 빛을 발하는 또 하나의 플래그가 바로 SA_ONESHOT(SA_RESETHAND)입니다. 이 녀석이 켜져 있으면, 핸들러를 일회용품처럼 딱 한 번만 쓰고 버립니다. 처리가 끝나는 순간 시그널 정책을 SIG_DFL(기본 동작)로 롤백시켜버리죠. 다음번에 같은 시그널이 온다면 핸들러가 아닌 시스템 기본 동작이 발동될 것입니다.

숨 가쁜 핸들러 실행 사이클을 정리해 볼까요: ① 커널이 유저 스택에 프레임 무대를 짓는다 → ② 레지스터를 비틀어 핸들러로 난입시킨다 → ③ 핸들러가 도는 동안 방해꾼 시그널을 차단한다 → ④ 끝난 후 sigreturn()이 마법처럼 예전 문맥으로 되돌린다.

프로세스가 read()와 같은 시스템 콜을 던졌지만 당장 데이터를 받을 수 없어 TASK_INTERRUPTIBLE 상태로 대기(sleep)에 들어간 상황을 가정해 봅시다. 이때 누군가 시그널을 쏴서 프로세스를 흔들어 깨우면 커널은 즉각 기상 조치를 취하지만, read() 시스템 콜 입장에서는 아직 임무를 완수하지 못한 난감한 상황입니다. 이때 시스템 콜은 커널 내부적으로 EINTR, ERESTARTNOHAND, ERESTART_RESTARTBLOCK, ERESTARTSYS 등 복잡한 에러 코드를 반환하며 후퇴합니다. 그리고 이 상황을 맞닥뜨린 사용자 프로그램이 최종적으로 받아보는 성적표가 바로 그 유명한 EINTR — "시그널의 난입으로 작업이 중단됨"입니다.

커널은 지금 깨어난 프로세스가 한창 시스템 콜을 돌리던 중이었는지 orig_eax 레지스터 값을 보고 눈치챕니다. 인터럽트로 들어왔다면 IRQ 번호에서 256을 뺀 음수 값이, 일반 예외라면 -1이 박혀 있지만, 시스템 콜 통로(int $0x80 또는 sysenter)로 들어왔다면 양수의 시스템 콜 번호가 당당히 들어있기 때문입니다. 즉, orig_eax가 0 이상이라면 "아, 이 녀석 시스템 콜 하다가 시그널 맞고 깨어났구나!" 하고 알아차리는 것입니다.

이 끊어진 시스템 콜을 부활시키려면 커널은 eax 레지스터에 원래 하려던 시스템 콜 번호를 다시 쥐여주고, 명령어 포인터(eip)를 시스템 콜 진입 명령(int $0x80) 바로 직전으로 뒤로 물립니다. x86 아키텍처에서 이 명령어의 길이가 딱 2바이트이므로, eip -= 2 연산 한 번이면 타임머신을 탄 것처럼 시스템 콜 진입 직전으로 되돌아갑니다.

시스템 콜 kill(pid, sig)은 그 무시무시한 이름과 달리 프로세스를 무조건 죽이는 함수가 아닙니다. 그저 지정한 타겟에게 sig 번호의 시그널을 쏘아 보내는 배달부일 뿐이며, 그 결과 프로세스가 죽을지 살지는 전달된 시그널의 성격과 타겟의 방어 태세(핸들러)에 달려 있습니다.

sys_kill()은 기본적으로 발신자 정보만 담긴 깡통 siginfo_t 조서를 작성합니다. 그다음 kill_something_info() 함수로 바통을 넘겨, 타겟의 성격에 따라 단일 타격(kill_proc_info()), 그룹 타격(kill_pg_info())을 결정지어 수행합니다.

tkill()과 tgkill()은 멀티스레드 환경에서 그룹 전체가 아닌, 스레드 하나(lightweight process)의 미간을 정확히 꿰뚫기 위해 등장한 스나이퍼 시스템 콜입니다. tkill(pid, sig)는 단순히 PID(스레드 ID)만으로 조준하고, tgkill(tgid, pid, sig)는 그 스레드가 속한 스레드 그룹 ID까지 교차 검증합니다. POSIX의 pthread_kill()은 내부적으로 이 날카로운 저격수들을 활용합니다.

sigaction(sig, act, oact)은 특정 시그널이 날아왔을 때 어떻게 대응할지 행동 강령을 설정하는 제어의 핵심입니다. act에는 당신이 정한 새 핸들러와 플래그, 차단 마스크가 담기고, 원한다면 oact를 통해 예전 강령을 백업받을 수 있습니다. 커널은 이를 받아 do_sigaction()을 통해 자료구조 속 action[sig-1] 위치에 이 강령을 깊숙이 새겨 넣습니다.

sigpending() 시스템 콜은 "현재 차단(block)되어 프로세스에 아직 전달되지 못한 대기 중인 시그널"의 목록을 확인하는 데 사용됩니다. 커널은 프로세스 개인의 큐와 그룹 큐의 비트를 OR 연산으로 합친 뒤, 현재 프로세스가 굳게 닫아걸고 있는 차단 마스크(blocked mask)와 AND 연산을 때립니다. 즉, "도착은 했는데 내가 막고 있어서 문밖에 서 있는" 녀석들만 추려서 사용자에게 보고합니다.

어떤 모드를 선택하든, 커널은 눈에 불을 켜고 SIGKILL과 SIGSTOP이 마스크에 섞여 있는지 검열해 가차 없이 쳐냅니다. 마스크 공사가 끝난 뒤에는 반드시 recalc_sigpending()을 호출하여, 방금 차단이 풀린 시그널들 중 곧바로 배달해야 할 대기 시그널이 있는지 장부를 다시 맞춥니다.

sigsuspend()는 아주 오묘한 콤보 시스템 콜입니다. 그 역할은 "잠시 이 임시 마스크를 쓰고 있을 테니, 내가 차단하지 않은 시그널이 날아와서 뺨을 때려줄 때까지 푹 자게 해다오"라는 뜻입니다. 기존의 마스크를 안전한 saveset에 킵해두고 새로운 마스크를 얼굴에 쓴 뒤, 프로세스를 TASK_INTERRUPTIBLE 상태로 재워버립니다. 시그널을 맞고 번쩍 눈을 뜨면 커널은 do_signal(regs, &saveset)을 호출해 시그널을 소화하게 하고, 이 모든 과정이 끝나면 최종적으로 -EINTR 에러를 뱉으며 화려하게 퇴장합니다.

실시간(real-time) 시그널 생태계에도 이와 똑같은 쌍둥이 시스템 콜들이 rt_sigaction(), rt_sigpending(), rt_sigprocmask(), rt_sigsuspend()라는 이름으로 포진해 있습니다. 특히 실시간의 꽃인 '큐잉(줄 세우기)'을 제대로 써먹으려면 두 가지 강력한 무기가 필요합니다. 하나는 rt_sigqueueinfo()(데이터를 얹어 그룹 공용 큐에 확실히 찔러넣는 전송용 콜)이고, 다른 하나는 rt_sigtimedwait()(문밖에서 대기 중인 시그널을 굳이 맞지 않고 안전하게 손으로 꺼내서 내용물만 확인하거나, 정해진 시간 동안 타임아웃을 걸고 기다리는 수신용 콜)입니다.