测验：取消按钮为何失效：控制通道与所有权

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

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

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

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

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

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

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

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

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

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

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

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