测验：大请求旁的小请求：就绪队列与公平性

ET 소켓에서 8KiB 중 1KiB만 읽고 예산을 소진했다. 다음 행동은?

• 준비 사실을 큐에 남기고 다른 연결 뒤에서 이어 읽는다
• 새 패킷이 올 때까지 준비 사실을 버리고 select한다
• 남은 데이터가 없다고 표시하고 읽기 관심을 해제한다
• 모든 다른 연결을 중단하고 해당 소켓만 끝까지 읽는다

준비 큐에 같은 연결을 select 반환마다 중복 추가하면 생기는 문제는?

• 커널 송신 버퍼가 큐 길이만큼 자동으로 축소된다
• 한 연결이 여러 자리를 차지해 메모리와 차례를 소비한다
• 동일 FD의 TCP 연결이 큐 항목마다 새로 생성된다
• 큐에 들어간 연결의 EOF가 자동으로 취소된다

논블로킹 recv를 EAGAIN까지 계속 호출한다. 왜 기아가 생길 수 있는가?

• 논블로킹 소켓은 두 번째 recv부터 반드시 잠들기 때문이다
• EAGAIN이 발생하면 모든 다른 소켓의 데이터가 삭제되기 때문이다
• 송신이 계속되면 한 연결의 처리 반복이 오래 지속될 수 있기 때문이다
• selector가 연결당 전용 스레드를 무제한으로 생성하기 때문이다

준비 큐에 처리할 항목이 남아 있다. 다음 select의 대기 정책은?

• 무조건 1초 대기해 모든 연결의 이벤트가 모이게 한다
• 큐가 비워질 때까지 제어 채널 등록을 해제해 둔다
• 큐 길이만큼 대기를 늘려 처리량 급증을 완화한다
• 대기를 0으로 하되 이번 턴의 처리 예산은 유지한다

FD 7을 닫은 뒤 새 연결도 FD 7을 받았다. 오래된 준비 작업과 구분하려면?

• 연결 객체 또는 FD와 세대 번호의 조합을 키로 삼는다
• 두 연결의 FD 숫자가 같으므로 같은 상태를 이어 쓴다
• 새 연결도 이전 오류를 상속하도록 결과를 복사한다
• 닫힌 FD의 이벤트가 절대 남지 않는다고 가정한다

공정성 실험에서 다음 커널 이벤트가 0개였다. 무엇을 결론 낼 수 있는가?

• 애플리케이션의 모든 입력 버퍼도 비었다고 확정한다
• 그 대기 호출의 알림이 없었으며 남은 바이트는 따로 확인한다
• 상대가 반드시 양방향 close를 완료했다고 확정한다
• 앞에서 읽은 바이트가 모두 상대에게 재전송됐다고 본다