퀴즈: 취소 버튼이 안 먹는다: 제어 채널과 소유권

문항 6개. 정답과 해설은 풀어 본 뒤에 보여 드립니다.

1. select에서 기다리는 루프에 정지를 요청할 때 올바른 순서는?

   1. 제어 바이트를 먼저 보내고 한참 뒤 Event를 설정한다
   2. Event를 먼저 설정한 다음 제어 소켓으로 깨운다
   3. 데이터 소켓을 다른 스레드에서 닫은 뒤 Event를 만든다
   4. select가 스스로 끝날 때까지 Event 설정을 미룬다

2. Event.set만 했는데 selector가 즉시 반환하지 않는다. 올바른 설명은?

   1. Event는 Python에서 어떤 스레드에도 관찰될 수 없는 변수다
   2. Event.set은 모든 소켓을 닫으므로 재생성해야 한다
   3. Event를 기다리는 것과 소켓 준비를 기다리는 것은 별개다
   4. selector가 Event를 읽으려면 관리자 권한이 필요하다

3. 정지 Event를 설정한 뒤 제어 send가 BlockingIOError를 냈다. 이번 계약에서는?

   1. 정지 상태를 지우고 사용자가 다시 누르기를 기다린다
   2. 요청 스레드에서 성공할 때까지 send를 무한 반복한다
   3. 제어 reader를 닫아 나머지 요청이 실패하도록 만든다
   4. 상태를 유지하고 이미 대기 중인 알림과 합쳐지게 둔다

4. 제어 drain에서 EAGAIN과 EOF를 같은 정상 빈 결과로 돌려도 되는가?

   1. EAGAIN은 지금 데이터 없음이고 EOF는 상대 종료이므로 구분한다
   2. 둘 다 정지 요청이 정확히 한 번 처리됐다는 동일한 증거다
   3. EOF만 다음 select에서 자동으로 새로운 제어 채널을 만든다
   4. EAGAIN은 영구 고장이므로 모든 경우 즉시 프로세스를 종료한다

5. 취소 요청 스레드가 직접 데이터 소켓을 닫지 않는 이유는?

   1. 다른 스레드는 어떤 상황에서도 Python 객체를 참조할 수 없다
   2. 루프가 등록 목록과 준비 큐를 함께 정리해야 소유권이 일관된다
   3. close를 호출하려면 반드시 원격 서버의 승인을 받아야 한다
   4. 데이터 소켓을 닫으면 제어 Event가 자동으로 False가 된다

6. 진단기 즉시 취소를 구현했다. 서버의 graceful shutdown도 완성됐는가?

   1. 취소가 있으면 어떤 프로토콜에서도 진행 중 응답이 자동 보존된다
   2. 모든 소켓을 닫으면 새 요청 거절 정책은 검토할 필요가 없다
   3. 요청 배출과 제한 시간 등 서버의 종료 정책은 별도로 설계해야 한다
   4. Control의 바이트 수를 늘리면 진행 중 거래도 자동 완료된다