이거 10장내용에서 나올 내용을 내가성급하게 앞서가는걸수도 있긴 한데,
인터럽트라는건 결국 현재의 context에 전달되는 개념일거야.
그렇다는건,
내가 트랩을 통해서 sleep 상태로 전환하는거 까진 좋아.
여기서 sleep 이라는것은 다시 커널의 자료구조상에서 프로세스 state로 관리되는걸거고,
스케쥴링에서 빠진 채로 컨텍스트 스위칭이 이루어지겠지(여기까진 트랩 핸들러가 작용)
그러면 그걸 깨우는걸 생각해보자고.
인터럽트가 sleep상태의 프로세스에 들어가나?
아니 애초에 sleep상태의 데이터 즉 context 한테 인터럽트를 전달한단게 무슨말이지? 그건 그냥 데이터란말이지.
결국
인터럽트는 현재 실행중인 프로세스가 받는다, 그리고 핸들러도 해당 컨텍스트 내에서 진행된다.
그러면, 해당 컨텍스트에서 실행된 핸들러가 어떻게
정확한 컨텍스트를 깨울 수 있을까?
인터럽트 자체가 메세지 패싱이 이뤄질 정도로 복잡한가?
그게 가능하면, IPC는 복잡하게 소켓 뚫을것도 없이
인터럽트로 처리가 가능할 것이다.
물론 현재에도 인터럽트 자체가 IPC의 수단이긴 하지만,
나는 인터럽트에 메세지를 담아서 보낸다는 개념은 들어본 적이 없다.
그러니까 인터럽트 자체는 단순히 핸들러를 실행하라는거고,
이때 핸들러를 실행하는동안 당연히 현재의 컨텍스트 내에는 핸들러에게 전달해줄 argument가 없다.
그렇다면,
데이터는 누가 보냈을까???
내 예상은
디스크 매니저??? 여튼 그새끼가 보냈다.
애초에 인터럽트 자체를 CPU에 보내준것도 그새끼다.
그새끼가 분명히 커널의 자료구조를 건드렸다.
아마 처음 선입명령을 받았을때, 어떤 프로세스가 (어떤 컨텍스트가) 선입을 요청했는지에 대한 정보를 받았을거다.
그리고, 선입이 완료되었을때, 커널을 손봐서 해당 컨텍스트의 sleep상태를 바꾸고, priority를 높인 후에 인터럽트를 보냈을거다.
B 가 문맥전환을 하면 자동으로 A로 전환되도록.
이게 내 추측이다. ㅇㅇㅇㅇㅇ
그리고,
음...
사실 이 추측을 뭐 진지빨고 한다기보단 더 근본적인 의문 때문에 하는건데,
CPU가 아닌 프로세서가 굉장히 많을거같다. 그리고 그녀석들도 나름 복잡한 개념들을 가지고 있을거 같다.
뭐 이건 메모리 하이라키를 볼 때에도 대충 등장했던 개념이었던거 같아 ㅇㅇㅇㅇ
내가 정확히 이해했는지, 뉘앙스를 잘 전달받았는지 좀 확실히 하고 싶은것일 뿐이고
예를들면 타이머, 그새끼도 프로세서인거같다
음.... 타이머같은경우는 운영체제가 타이머를 몇번 받았는지에 따라서 카운트가 가능하려나. 좀 어렵네 근데 그런 가정이면, 타이머로부터 매 틱을 받을떄마다 틱 카운트를 증가시켜가면서 sleep을 꺠우는지 여부를 따져야하나??? 오버헤드일거같은데. 좀 어렵네
음? 인터럽트하는 건 시그널로 하는 건데.
https://man7.org/linux/man-pages/man7/signal.7.html
그 CPU 하드웨어 인터럽트 그런 거랑 헷갈리면 안 됨.
기본적으로는 해당 시그널을 io device 가 보내는거같은데
근데 시그널을 프로세스한테 보내는거 같은데, 그렇게 보면 내가 좀 상태가 안좋다. 음.... 어렵네. 자고있는 프로세스가 시그널을 받는거처럼 처리된단말이지
너무 어렵다 ㅠㅠㅠㅠ
read blocking 상태가 interrupt되는 건 시그널로 인터럽트 되는 거고, read blocking 상태가 IO 완료 혹은 실패되어 blocking이 풀리는 과정은 오히려 하드웨어 인터럽트 그런 걸 적은대로 생각을 전개해볼 수 있지.
하드웨어 인터럽트가 CPU의 인터럽트랑 다른 개념인가? 나는 프로세스가 직접 시그널을 보내는거는 CPU 본인이 자기 자신한테 인터럽트를 보냈다고 생각했는데 여기서 근데 해당 인터럽트가 자고있는 컨텍스트에 전달된다는 개념이 좀 어려움
그리고 왠지 SIGIO 이런 시그널이 io디바이스로부터 CPU로 전달될거같은데, 해당 시그널의 디폴트값 이런거에 terminate 이런거 붙어있는거도 이해가 잘 안가고