문서화되지 않은 "EINTR"을 사용한 시스템 호출이 "EINTR"을 반환할 수 있습니까?

문서화되지 않은 "EINTR"을 사용한 시스템 호출이 "EINTR"을 반환할 수 있습니까?

저는 작은 응용 프로그램을 작성 중이며 가능한 한 이식 가능하게 만들고 싶습니다(Linux, *BSD 및 기타 UNIX). 내 주요 문제는 관리입니다 EINTR. 일부 시스템에는 EINTR문서화되지 않았지만 반환할 수 있는 시스템 호출이 있다는 것을 읽었습니다 (예:stat(2)리눅스에서). 맞습니까?

EINTR현재 해결 방법은 이 오류를 반환하지 않는 것으로 기록되더라도 모든 시스템 호출에 래퍼를 사용하여 재시도하는 것입니다 . 모든 "POSIX 호환" 시스템에서 안전합니까? 이 접근 방식을 사용하면 어떤 문제가 발생할 수 있습니까? 정말 권장/필수인가요?

답변1

일부 시스템의 일부 시스템 호출은 EINTR을 반환할 수 있다는 내용을 읽었습니다. 비록 문서화되어 있지는 않지만(예: Linux의 stat(2)). 맞습니까?

모든 신호를 차단하지 않는 한 I/O를 차단할 수 있는 모든 시스템 호출은 반환될 수 있습니다 EINTR. 이는 커널의 일반적인 동작이므로 이러한 모든 시스템 호출에 대해 반복적으로 문서화되지 않은 것이 합리적입니다. 또한 중복된 문서를 찾고 싶지도 않습니다.EIO같은 이유로 모든 I/O 시스템 호출에서.

더 광범위하게 말하면 Linux 매뉴얼 페이지는 반환할 수 있는 오류의 전체 목록을 제공하지 않습니다. 위의 상황뿐만 아니라 커널에는 많은 레이어가 있는데 각 syscal의 역할은 무엇입니까?할 수 있는보상은 어떤 운전자가 참여하는지 등에 따라 달라집니다. XFS 파일 시스템의 파일을 참조할 때 -1이 반환되면 errno-1이 반환될 때 가능한 값 세트는 read(2)FIFO를 참조할 때와 달라집니다. fd매뉴얼 페이지에서 가능한 모든 오류 반환 코드를 제공할 것이라고 기대하는 것은 무리입니다.errno(3)그렇다면.

이 접근 방식을 사용하면 어떤 문제가 발생할 수 있습니까? 정말 권장/필수인가요?

맹목적으로 시스템 호출을 다시 시작하는 것은 애플리케이션에서 올바른 접근 방식이 아닐 수 있습니다. 시스템 호출 반환은 EINTR애플리케이션이 신호 처리기의 컨텍스트가 아닌 호출 컨텍스트에서 신호를 처리할 수 있는 기회를 제공합니다. 예를 들어, 이는 전역 변수를 방지하는 데 도움이 될 수 있습니다.

이 문제에 대한 한 가지 관점은 다음을 참조하세요.EINTR그 장점은 무엇입니까.

또한 sigaction해당 기사에서 지적한 사항에 유의하십시오. 다음을 사용하여 이 동작을 제어할 수 있습니다.SA_RESTART. 다음 질문이 이 플래그를 1로 설정해야 하는지 아니면 0으로 설정해야 하는지 묻는다면 대답은 애플리케이션에 따라 다르다는 것입니다.

관련 정보