15. IPC(1)

안녕하세요. 오늘은 IPC에 대해 알아보겠습니다. 저번 포스팅을 끝으로 프로세스에 대해 알아보았었는데요. 프로그램과 프로세스, 문맥전환, 프로세스 상태, linux에서의 프로세스 생성에 대해 설명드렸습니다. 지금까지는 single core를 가정하고 이야기를 많이 하였습니다. 여기서 조금 확장해볼까요? 만약 여러분에게 이미 완성된 프로그램이 있다고 생각해보죠. 처음에 이 프로그램은 thread를 하나만 사용하는 single thread 프로그램으로 개발되었습니다. 이 프로그램이 멀티코어를 사용하도록 바꾸려면 어떻게 해야 할까요?

 

컴퓨터 구조 과목에 대한 기초적인 이해가 있는 분들은 답변하실 수도 있겠군요. 멀티코어. 즉, 멀티스레드가 되려면 각 스레드는 결국 하나의 프로세스이니 따로 놀면 안되고 서로 협력해야 합니다. 협력하기 위해 도구로 IPC를 연구하게 된거죠. 이처럼 멀티 프로세서나 멀티코어로 인한 성능을 온전히 활용하고자 한 것도 IPC를 연구하기 시작한 이유 중 하나입니다.

 

IPC는 프로세스 간 통신(Inter Process Communication)로 프로세스들 사이 서로 데이터를 주고받는 행위, 방법, 경로를 뜻합니다. 

 

Data transmission, Data sharing, Event Alarm, Resource sharing

 

위와 같은 역할을 할 수 있고요. 

 

15.01. IPC Model

 

Interprocess Communication(IPC)

 

IPC는 프로세스 간 데이터와 정보를 주고받기 위한 메커니즘입니다. 같은 컴퓨터에서 돌아가는 프로세스끼리 그냥 다른 프로세스에게 도와달라고 하면 안되냐고요? 아니면 메모리를 그냥 보면 되지 않냐고요?

No. 단호하게 그냥은 안 된다고 말할 수 있어야 합니다. Protection domain때문에 서로 호출하거나 접근하는 것이 불가능합니다.

 

그래서 IPC같은 mechanism을 제공하고 커널에서 IPC를 위한 도구를 제공해주는 것이죠. 이때 왜 커널이 관여하는지 어떠한 형태로 제공하는지 지금 머릿속에 떠올려보시기 바랍니다. 나중에 자세히 설명하겠지만 시스템 콜 형태라는 힌트를 드려봅니다.

 

IPC는 요즘 대세(?)인 AI에서도 꼭 필요한 존재입니다. 

 

Cooperating process model

 

프로세스 협력 모델을 구현하기 위해서도 IPC가 반드시 필요하죠. 여러 worker(프로세스라고 생각하시면 됩니다.)가 data set을 쪼개어 일을 수행하면서 IPC를 통해 서로 데이터를 교환할 수 있습니다. Deep learning에서도 처리할 데이터가 많아 여러 개의 프로세스가 나누어 처리하는데 이때 communication이슈가 있을 수 있죠.

 

15.01.1. Memory shared

첫번째로 살펴볼 모델은 메모리 공유 모델입니다. Proection domain 개념 자체에 대해 반기(?)를 드는 모델이라 할 수 있겠군요. 프로세스의 특정 메모리 영역을 공유하여 읽기/쓰기를 통해 프로세스간 통신을 수행하는데 사용하는 것입니다.(공유하는 프로세스 모두에게 자신의 메모리로 보이죠.) 따라서 공유 메모리가 설정이 될 때 커널이 관여하고 그 이후에는 프로세스 각자가 자기의 address space에 읽고 쓰듯이 load, store를 하면 되기 때문에 커널이 관여를 하지 않게 됩니다.(그래서 force sharing이라는 표현을 잘 쓰진 않지만 하기도 합니다.) Worker들이 동시에 작업하는 것도 이런 모델을 사용하기 때문이죠.

 

15.01.2. Message passing

이번에 살펴볼 모델은 message passing입니다. 메모리 공유를 설명하며 worker가 동시에 작업한다고 하였는데 parameter server와 worker가 데이터를 주고 받는 것은 메시지 교환 모델을 따릅니다.(인공지능 학습 : 모델의 매개변수를 분산형 환경에서 추적하는 작업) 클라이언트와 서버 방식의 통신으로 소개해드리는 것이 더 이해하기 쉬울 수도 있겠군요. 그렇다면 프로세스가 protection domain인데 어떻게 메시지를 주고 받을 수 있을지 궁금해하셔야 합니다. 어떻게 메시지를 주고받을 수 있을까요?

메모리 공유 모델이 그렇듯이 이때도 커널이 common하게 공통적으로 존재하기 때문에 가능합니다. 뒤이어 설명하겠지만 pipe, message queue, socket등으로 구현합니다.

 

15.01.3. Memory shared vs Message passing

메모리 공유 방식은 프로세스의 주소 공간의 일부를 공유 메모리 영역으로 설정하여 프로세스에서 바로 접근합니다. 하지만 메시지 교환 방식은 send & receive방식이기 때문에 커널을 경유하여 메시지를 전송하죠. 따라서 커널에서 데이터를 처리할 일종의 버퍼가 필요합니다. 또한 메시지를 기다리면서 문맥전환이 발생하죠. 가장 중요한 것은 속도입니다.

 

속도 : 공유 메모리 모델 > 메시지 교환 모델

 

공유 메모리 모델이 메시지 교환 모델보다 속도가 빠릅니다.(커널의 도움을 받아야하기 때문입니다. 이 부분은 overhaed가 됩니다. 하지만 core가 많은 시스템의 경우 메시지 전달 모델이 메모리 공유 모델보다 빠를 수도 있습니다. chache coherence protocol때문이죠.) 그렇다면 메모리 공유 모델의 단점은 무엇일까요?

Process A와 Process B가 있다고 할 때, A와 B가 같은 주소에 store한다면요? 앞서 말씀드렸다시피 프로세스는 자신의 메모리로 생각할 뿐더러 A와 B는 서로 무엇을 하는지 알기 어렵습니다. 이 문제는 나중에 살펴볼 매우 중요한 이슈인 동기화 문제입니다. 또한 메시지 전달 방식이 아니기 때문에 data를 읽어야하는 시점을 정확히 알기 어렵습니다. 

 

Message passing에서 read를 할때 polling을 사용하나요?

사용할 수는 있지만 하지 않습니다. send 자체도 커널로 메시지가 복사되어야 하는 과정이 있어 message passing 자체가 시간이 걸리는 model입니다. CPU입장에서 폴링을 사용하기엔 비효율적입니다.(폴링의 오버헤드가 크지 않다고 확실시 될 때만 사용합니다.) 폴링은 보통 디바이스 I/O를 할 때 굉장히 빠르면(빈번하다면) 사용하는 방식입니다.

 

공유 메모리 model에서 update 여부는 어떻게 알 수 있을까요?

앞서 말씀드렸다시피 update되었는지는 값을 계속 비교해야 하기 때문에 확인하기 어렵습니다. 폴링이 하나의 방법이 될 수 있을 겁니다. 또 다른 방법은 A가 update했다고 notification을 하는 것이죠.(signal을 사용해볼 수 있습니다. 그러면 기다리고 있다가 wake해서 signal handler에서 읽어갈 수 있죠.) dirty bit를 사용할수도 있을 것 같습니다.

 

 

15.02. IPC와 동기화

메모리 공유 모델과 메시지 전달 모델을 살펴보면서 동기화 이슈에 대해 언급하였습니다. 동기화 자체에 대해서는 아주 공부할 거리가 많은 topic이기 때문에 설명하지 않을 것이고 IPC에서 동기화가 왜 필요한지에 대해서 설명하도록 하겠습니다. 

 

일단, 메모리 공유 모델에서는 앞서 말씀드렸지만 사용자가 동기화를 제공해야 합니다. 메모리 영역에 대한 동시적인 접근을 제어하기 위한 방법이 필요하죠.(locking, semaphore등이 있는데 이는 아주 긴 이야기가 될테니 동기화 포스팅에서 다루겠습니다.) Process A와  Process B가 있다고 할 때, 만약 동시에 같은 주소에 작성한다면(overwriting) 둘 중 하나의 값이 무시될 수 있습니다. 심지어 Process B가 Process A가 write한 값을 읽어야 된다면 큰 문제일 겁니다. 앞서 커널은 공유 메모리를 만들어주고 그 이후로 관여하지 않는다고 하였는데요. 동기화를 프로세스들이 서로 해줘야 한다는 것이 큰 단점입니다. 생각보다 복잡한 이슈거든요.(여러분이 커널이나 thread를 공부하신다면 동기화 이슈는 피할 수 없습니다. 일반적으로 sequential하게 coding할 때는 동기화 이슈를 별로 고민하지 않았습니다. 여러분이 학부 기초과목으로 배우는 C프로그래밍 같은 수업에서 step by step을 우습게 보고 넘어가셨다면 이제부터 아주 고마운 단어라고 생각하시게 될겁니다. Execution 자체가 step by step이라는 것은 아주 중요한 특징이죠.) 

 

메시지 전달 모델은 커널이 동기화를 제공해줄 수 있습니다. send와 recieve같은 연산에 대해 커널이 동기화를 제공해준다면 프로세스에서는 동기화에 대한 고려없이 send와 recieve를 자유롭게 사용하면 되죠. 커널이 동기화한다는 것에 대해 예를 들어 보겠습니다. A가 패킷을 보냈을 때 B는 언제 받을지 알 수 없습니다. 이때 보낸 패킷은 중간 어딘가에 있어야합니다. 바로 Kernel buffer입니다. 중요한 것은 send와 recieve가 같이 이루어지진 않는다는 것입니다. 이 차이를 어떻게 맞출 수 있느냐의 문제는 결국 커널이 동기화를 해주어 해결합니다.(B가 받아야 하는데 A가 아직 보내지 않았을 때도 커널이 도와줍니다. B가 A가 메시지를 보냈을 때 사용하는 버퍼에서 기다리는 방식이 사용될 수 있죠.) 즉, 어떤 순서로 받을것인지는 커널이 알아서 해줍니다.

반응형

 

15.03. Memory shared Case

15.03.1. Shared memory_Memory shared

이제부터 구체적인 메커니즘 : 테크닉에 대해서 알아보겠습니다.

 

메모리 공유 모델을 그대로 가져온 method입니다. 여러 개의 프로세스들이 하나의 메모리 영역을 공유하여 통신을 하는 기법입니다. 앞서 메모리 공유 모델과 메시지 교환 모델을 비교할 때도 말씀드렸다시피 메모리의 직접 사용으로 빠르고 자유로운 통신이 가능합니다. 다만 동기화 이슈가 있습니다. 여기서 자유로운 통신이라는 것은 나중에 살펴볼 일대일 통신만 가능한 pipe에 비해 많은 프로세스가 붙을 수 있다는 뜻입니다. 또한 pipe와 같은 경우에는 보내는 순서와 받는 순서가 같다는 중요한 특성이 있지만 shared memory 방식에서는 그러한 order가 존재하지 않습니다.

 

 

15.04. Message passing Case

15.04.1. Pipe_Message passing 

Pipe는 하나의 프로세스가 다른 프로세스로 데이터를 직접 전달하는 기법입니다. 데이터가 half duplex하기 때문에 양방향 통신을 하기 위해서는 두 개의 파이프가 필요합니다. 보통 사용하는(packet) message passing은 ordering property가 필요 없습니다. 즉, 보내는 순서와 받는 순서가 일치하지 않는다는 거죠. 하지만 파이프는 보내어진 순서대로만 받습니다. 만약 파이프가 꽉 차면(커널 내의 버퍼가 꽉 찼다는 것입니다.) 더 이상 쓸 수가 없습니다. 그만큼 read처리를 빨리 해줘야겠죠. 여러가지 제약이 있긴하지만 간단하게 데이터를 주고받는 방법 중 하나입니다.

 

15.04.2. Signal_Message passing

Signal은 이벤트를 전달하는 기법입니다. 여러 신호는 signal.h에 정의되어 있습니다.(Null pointer 관련 signal도 있죠. 자주 접해보셨을 겁니다.) 특정 프로세스에게 보내는데 이는 수신할 프로세스의 상태와 무관합니다. 수신한 프로세스는 무시하거나 붙잡아두거나 Signal handler를 수행합니다. 또한 비동기적인 동작으로 수신한 프로세스 자체가 스케쥴링 되어야 처리가 가능합니다. 즉, process A가 실행중에 process B에게 signal 보내면 B 자체가 실행될 때 signal을 처리한다는 것이죠.(사실 signal handler가 수행된다는 것 자체가 B가 run queue에서 CPU를 사용하고 있다는 의미입니다.)

 

Signal handler(Interesting topic to study)

 

C 프로그램에서 null pointer에 접근하면 어떤 일이 벌어질까요?

해당 프로세스는 terminate할 겁니다.

Null pointer dereference : 대부분의 운영체제에서는 이 널 포인터를 메모리의 첫 페이지 주소 0(0x00000000)로 사용하고 있습니다. 여기에 접근하면 보통 프로그램이 비정상적으로 종료됩니다.(segmentation fault)

 

UNIX 계열 OS에서 잘못된 메모리에 접근하는 프로세스는 SIGSEGV signal을 받습니다. MS windows에서는 STATUS_ACCESS_VIOLATION 예외 처리를 받죠. Trap에 대해 기억나지 않으신 분들은 아래의 글을 참고해주시기 바랍니다.

2021.11.08 - [학부공부/OS_운영체제] - 08. 운영체제와 컴퓨터 구조(1)

08. 운영체제와 컴퓨터 구조(1)

Null pointer, divided by 0 같은 경우 trap handler가 작동한다고 말씀드렸는데요. 이때 exception을 발생시킨 프로세스에 signal을 보냅니다. 더 이상 execution을 못하게 되고(fail) 커널은 프로세스를 쳐내게 됩니다.(kill : kill은 signal handler가 없습니다.) 

 

 

다른 프로세스에게 alarm을 보내는 등 다양한 signal들이 존재합니다. 메모리 상태를 watch하면서 일정 이상으로 내려가면 프로세스가 다른 프로세스 모두에게 signal을 보내는 경우도 있죠.(실제로 안드로이드에서 메모리가 부족할 때 이렇게 합니다.) 인터럽트는 하드웨어적으로 device가 generation하는 느낌이라면 signal은 발생하면 안되는 일이 발생했을 때 소프트웨어가 사용할 수 있는 방법이라고 할 수 있습니다.(즉, 하드웨어가 아닌 process가 signal을 생성합니다.)

 

Kill은 signal handler가 없다고 했는데, signal handler가 없는 다른 case는요?

없으면 프로세스는 죽습니다. 있으면 handler를 실행하죠.(Trap, interrupt handler의 역할을 한다고 볼 수 있습니다.) 또는 붙잡아 둘 수도 있습니다. 받았다는 것을 eco하는 것이죠. 참고로 kill은 signal handler가 없기 때문에 권한이 있는 user가 보내게 합니다.(자식 프로세스를 만든 프로세스에서 kill할 수 있는 것이 예가 될 수 있겠군요.) 왜 ignore하지 않고 terminate하는 지에 대해서는 보안 관점에서 그렇게 만든게 아닐까 생각합니다. 악의적으로 프로세스를 죽일 수 있다면 hacking의 도구로 사용될 수 있으니까요. 그리고 signal handler를 만들어 사용하라는 철학도 어느정도 있습니다.(웹서버처럼 거대한(?)시스템을 만든다면 signal handler 문제는 알아서 catch하라는 어떤 시스템에 대한 이해를 전제로 하는거죠.) 또한 ignore하게 되면 실제로 terminate할 수 있을 때 못하게 될 수도 있습니다. 이런 것은 policy 이슈라고도 볼 수 있습니다. 조금 더 general하게 만드려고 한거겠죠.(그래서 프로세스가 갑자기 죽는다면 다른 프로세스가 signal을 보내서 죽는 경우도 있을 수 있습니다.)

 

마지막으로 덧붙이자면 tensorflow같은 code를 보면 제일 먼저 하는 것이 signal을 전부 ignore하는 것을 만들어 놓습니다. 왜냐하면 의도하지 않아도 서버가 죽는 경우를 막기 위해서죠. 웹서버 signal을 ignore하지 않는다면 외부에서 쉽게 서버를 죽일 수도 있을 겁니다.(저는 못하지만요.) 일반적으로 coding할 때 signal handler를 모두 정의한다는 것은 굉장히 안정적인 프로그램을 만들 수 있는 방법 중 하나입니다. 그게 없으면 모르는 프로세스가 signal을 툭하고 주면 프로세스가 그냥 죽어버릴 수 있기 때문이죠.

 

Pipe와 비교한다면요?

Pipe는 일종의 긴밀한 데이터 교환입니다. 다른 프로세스에게는 두 프로세스 사이의 pipe가 보이지 않기 때문이죠. Signal은 데이터 교환이 아닌 상태를 알려주거나 event를 알리는 notification 역할입니다.(광의적으로 보았을 때 IPC에 포함하는거죠. communication에 데이터 교환과 notification이 모두 포함됩니다.)

 

Signal에도 우선순위가 존재하나요?

인터럽트는 우선순위가 있었으니 signal도 있을 수 있겠다 생각하시는 분들도 계실겁니다. 앞에서 인터럽트는 하드웨어적이라고 말씀드렸는데요. 인터럽트는 종류가 별로 없습니다. Signal은 종류가 굉장히 많죠. 따라서 순서대로 delivery 시킵니다. 우선순위를 따지기 힘들기 때문입니다.(구체적으로 들어가 보자면 인터럽트와 signal은 용도가 좀 다릅니다. 인터럽트가 발생했다는 것은 굉장히 구체적인 경우죠. 그에 비해 signal은 프로세스 간의 굉장히 다양한 interaction을 가능하게 해줍니다.)

 

그렇다면 Signal은 어떻게 delivery될까요?

컴퓨터 구조 과목을 배우신 분들이라면 생각해 낼 수 있습니다.(수신한 프로세스가 스케쥴링되면 처리한다는 것을 참고하세요.)

System call. 프로세스가 그냥 다른 프로세스에게 보낼 수 없습니다. PCB(Process control block)가 프로세스마다 존재합니다. 프로세스가 signal을 호출하면 argument는 누구한테 보낼지, 어떤 종류인지 최소 이 2가지가 필요합니다. 커널이 프로세스의 PCB에 표시(mark)해 줄 수 있죠. Context switching을 할 때 어차피 state를 loading하기 위해 PCB를 보아야 합니다 그때 커널의 dispatcher가 이런 역할을 해줄 수 있습니다.(프로세스의 PC(program counter)를 signal 처리 routine 주소로 지정하고 handler로 전달할 인자를 stack이나 register에 저장합니다.)

 

앞서 인터럽트는 하드웨어가 signal은 process가 generate한다고 했는데요. 조금 더 엄밀하게 표현하자면 signal은 커널이 generate한다고 표현할 수 있습니다.(trap handler, kernel도 일종의 소프트웨어로 볼 수 있죠) 왜 커널의 도움을 받아야 물으신다면 protection domain때문입니다. 물론 pipe도 커널의 도움을 받습니다. Implementation detail이라 version마다 다를 수 있지만 개념적인 동작은 같습니다.

 

 

마지막으로 정리하자면 signal을 발생시키는 event는 시스템 콜(kill), 사용자 입력(^c, ^z 등), hardware exception(나누기 0 등), software condition(alarm)로 크게 볼 수 있고요. 아래의 표와 같은 예가 있습니다.

Signal
SIGKILL	프로세스 kill
SIGALARM	alarm
SIGSTP	프로세스 멈춤
SIGCONT	멈춰진 프로세스 동작
SIGINT	프로세스 인터럽트 발생
SIGSEGV	프로세스가 다른 메모리 영역을 침범

 

 

15.04.3. Message Queue

Message queue방식은 고정된 size의 queue를 이용하는 기법입니다. Shared memory와 pipe의 중간 수준이라고 할 수 있습니다. 통신하고자 하는 프로세스간 약속(사용자가 정의)을 하여 메시지 단위의 통신을 합니다. 여러 프로세스가 동시에 접근이 가능하면서 order도 어느정도 지킨다는 점에서 pipe보다 general하다고 볼 수 있습니다.(n : m도 가능합니다.) 다만 동기화가 필요합니다. 그래서 linux kernel에서 관리하고 모든 프로세스에서 접근이 가능하도록 구현은 되어 있습니다. 장점은 비동기적이기 때문에 큐에 넣은 후 천천히 처리할 수 있다는 것과 분산처리 방식에 사용할 수 있다는 것입니다.(다른 참고문헌에는 비동기, 탄력성, 확장성, 비동조 등 다양한 장점을 열거하더군요.) 하지만 메시지가 잘 전달되었는지 확인하는 것이 어렵다는 점이 단저입니다.

 

조금 더 살펴보자면 Message는 Header와 Text로 구성되고요. Header부분에 메시지의 type을 나타내는 값을 붙일 수 있고 이를 통해 선택적으로 읽는 것이 가능합니다. include/linux/msg.h에 struct msg_msg로 정의되어 있으니 직접 보는 것도 좋을 것 같습니다. Message Queue의 구조를 살펴보면 msg_queue structure는 permission 정보, 큐의 bytes, message 수 등의 정보를 가지고 있고 위에서 언급한 경로와 동일한 경로에 struct msg_queue로 정의되어 있습니다. 각각의 메시지와 linked list 구조로 연결되어 있으며 q_messages는 메시지 큐의 가장 앞쪽 메시지와 연결되고 각각의 메시지는 m_list를 통해 연결됩니다.

Meaage queue가 생성될 때는 정보를 가진 객체가 생성되는데 마지막으로 송수신한 프로세스 ID, 송수신 시간 등의 정보가 있고 include/uapi/linux/msg.h에 struct msqid_ds로 정의되어 있습니다. 

 

15.04.4. Socket

Socket은 abstraction에 대해 소개한 포스팅에서 endpoint for communication이라고 설명한 바 있습니다. Bound a port라고 정의할 수도 있습니다.(port는 OS에서 제공하는 abstraction이고 socket을 프로세스에서 port를 바라보는 창으로 여길 수 있다는 의미입니다.) 여러 개의 웹이 돌아간다면 port를 바라보는 각 프로세스 별로 무언가가 필요합니다. 그것이 바로 소켓입니다. 그래서 endpoint라고 정의할 수 있는 것입니다. 포트번호를 이용하여 통신하려는 상대 프로세스의 소켓을 찾아가는 거죠. 예를 들면 웹서버의 X번 포트 > 서버 컴퓨터에서 실행중인 웹서버 프로세스가 사용하는 소켓 ID로 연결지을 수 있습니다.

 

다른 IPC와 달리 새로운 dimension을 제공한다는 측면에서도 아주 중요합니다. 지금까지 살펴본 IPC 기법들은 하나의 기계 안에서만 의미가 있었습니다. 즉, 다른 machine boundary의 다른 프로세스에 signal을 보낼 수 없었습니다. 하지만 소켓은 포트의 도움을 통해 프로세스의 위치에 독립적으로 작동할 수 있습니다.(Local의 경우에는 포트번호로 식별하고 remote의 경우는 IP주소와 포트번호 조합으로 식별하는 거죠.) 위치라는 관점에서 소켓이 굉장히 general한 interface라는 것입니다. 

 

소켓이 communication end point통신을 할 때, 패킷을 잃어버려도 괜찮느냐의 semantics를 지원하기도 합니다.(Reliable : TCP, Unreliable : UDP) 여기서 reliable에는 order도 포함됩니다. 네트워크에서 order는 중요한 성질 중 하나입니다. 기본적으로 길이 다르기 때문에 망은 unreliable합니다. Reliable 특성을 주면 운영체제가 reliable한 역할을 할 수 있어 중요합니다. 자세한 내용은 컴퓨터 네트워크 과목에서 배울 수 있습니다. 

 

Machine independent와 관련하여 좋은 그림이 있어 가져와 보았습니다. 포트를 사용하기 때문에 machine boundary와 관계가 없고 remote machine은 local machine의 port만 볼 수 있습니다. 프로세스는 소켓을 통하여 패킷을 주고 받습니다.

Port(Interesting topic to study)

 

소켓의 장점을 정리하자면 서버&클라이언트 환경을 구축하는데 용이하고 범용적인 IPC로 사용이 가능하다는 점, 패킷 단위로 주고받아 직관적으로 이해하기 쉬운 code로 작성할 수 있으며 Unix Domain Socket인 UDS는 pipe와 같은 형태로 이루어져 패킷이 유실되거나, 순서가 바뀌는 문제가 발생하지 않는다는 점입니다

 

 

오늘은 IPC에 대해 알아보았습니다. 2가지 model에 대해 살펴보았고요. 각 model에 따른 메커니즘들도 살펴보았습니다. 특히 signal에 대해 많은 부분을 할애하여 설명하였습니다. 그만큼 signal은 공부하면 할수록 굉장히 복잡한 topic이였습니다. 네트워크 과목에서 다룰 socket에 대해서도 맛만 보았습니다. 각 메커니즘 별 구체적인 예제들은 다음 시간에 알아보도록 하겠습니다. 질문과 의견, 후기는 언제나 환영하고요. 긴 글 읽어주셔서 감사합니다.