Quick Reference
프로세스는 생성·실행·종료 경계를 기준으로 자원과 복구를 관리하고, IPC는 그 경계를 넘는 데이터 전달 방식입니다. IPC는 API보다 격리 범위와 상대 종료, stream framing, 복구 정책을 먼저 정해 선택합니다.
| 필요 | 먼저 검토할 IPC |
|---|---|
| 부모·자식의 단방향 byte stream | anonymous pipe |
| 같은 machine의 이름 있는 통신 | named pipe 또는 local socket |
| machine을 넘는 요청·응답 | network socket 또는 RPC |
| 큰 데이터를 복사 없이 공유 | shared memory + 별도 synchronization |
수명 경계
Process handle과 PID는 process 객체를 다루는 식별 수단이지만 같은 것이 아닙니다. Handle은 접근 권한과 kernel object 수명에 연결되고 사용 후 닫아야 합니다. PID는 재사용될 수 있으므로 오래 저장한 PID만으로 같은 process라고 판단하지 않습니다.
자식 process 종료를 기다릴지, 독립 실행으로 둘지, 부모 종료 시 함께 정리할지는 생성 시점에 결정해야 합니다. 강제 종료는 finally나 destructor 같은 user-mode 정리 코드를 보장하지 않으므로 공유 상태를 손상시키지 않는 복구 경계가 필요합니다.
메시지 경계
Pipe와 TCP socket은 byte stream일 수 있어 한 번의 write와 한 번의 read가 같은 메시지 단위로 대응한다고 가정할 수 없습니다. 길이 prefix, delimiter, 고정 frame처럼 메시지 framing을 설계합니다.
Shared memory는 serialization과 복사를 줄일 수 있지만 pointer를 그대로 공유할 수 있다는 뜻은 아닙니다. 프로세스마다 mapping 주소가 다를 수 있고 lock, version, ownership, crash recovery를 함께 설계해야 합니다.
자주 틀리는 점
- IPC가 process 격리의 모든 오류를 막지는 않습니다. 잘못된 메시지는 논리 상태를 깨뜨릴 수 있습니다.
- 상대 종료를 정상적인 입력 상태로 처리합니다.
- Handle 상속은 필요한 것만 명시적으로 허용합니다.
- shared memory를 사용하면서 synchronization 비용을 계산에서 빼지 않습니다.
참고 링크
2 sources