왜 fork()가 파일 설명자를 반환하도록 설계해야 합니까?

왜 fork()가 파일 설명자를 반환하도록 설계해야 합니까?

그의페이지 소개이것자기 관리 기술, Dan Bernstein은 및 신호 측면에서 경쟁 조건을 설명하고 select()해결 방법을 제공하며 다음과 같이 결론을 내립니다.

물론 올바른 방법은 fork()프로세스 ID가 아닌 파일 설명자를 반환하는 것입니다.

이것이 의미하는 바는 - select()이러한 상태 변경에 대한 알림을 받기 위해 신호 처리기를 사용하는 대신 하위 프로세스의 상태 변경을 자체적으로 처리하는 것이 가능합니까?

답변1

문제는 소스 코드에 설명되어 있으며 select()this 와 같은 신호로 중단되어야 SIGCHLD하지만 어떤 경우에는 제대로 작동하지 않습니다. 따라서 해결책은 신호를 파이프에 쓴 다음 이를 모니터링하는 것입니다 select(). 파일 설명자를 모니터링하는 것은 이 문제를 해결하도록 설계되었습니다 select().

해결 방법은 기본적으로 신호 이벤트를 파일 설명자 이벤트로 변환합니다. fd가 먼저 반환 되면 fork()해결 방법이 필요하지 않습니다. 해당 fd는 아마도 와 함께 직접 사용될 수 있기 때문입니다 select().

네, 마지막 단락의 설명이 제 생각에는 맞는 것 같습니다.


fd(또는 다른 유형의 커널 핸들)가 일반 프로세스 ID 번호보다 나은 또 다른 이유는 프로세스가 종료된 후 PID를 재사용할 수 있다는 것입니다. 어떤 경우에는 프로세스에 신호를 보낼 때 문제가 될 수 있으며 해당 프로세스가 동일한 PID를 재사용하는 다른 프로세스가 아니라 생각하는 프로세스인지 확인하는 것이 불가능할 수 있습니다. (비록 자식 프로세스에 신호를 보낼 때 이것이 문제가 된다고 생각하지는 않지만, wait()PID를 해제하려면 부모 프로세스가 자식 프로세스에서 실행되어야 하기 때문입니다.)

답변2

Bernstein은 이 "올바른 일" 코멘트에 대해 많은 맥락을 제공하지 않지만 추측할 위험이 있습니다. fork(2)가 PID를 반환하는 것은 open(2), creat(2) 등과 일치하지 않습니다. 파일 설명자. 나머지 Unix 시스템에서는 PID 대신 프로세스를 나타내는 파일 설명자를 사용하여 프로세스 작업을 완료할 수 있습니다. 시스템 호출signalfd(2)이는 신호와 파일 설명자 간의 더 나은 상호 작용을 허용하고 프로세스를 나타내는 파일 설명자가 작동할 수 있음을 보여줍니다.

답변3

이것은 단지 "유닉스를 지금과 다르게 디자인했으면 좋겠다"는 반성일 뿐입니다.

PID의 문제점은 PID가 다른 프로세스에 재사용될 수 있는 전역 네임스페이스에 있다는 점이며, fork()항상 하위 프로세스를 참조하도록 보장되는 일종의 핸들이 상위 프로세스에서 반환된다면 좋을 것입니다. 상속이나 Unix 소켓을 통해 다른 프로세스로 전달될 수 있습니다 SCM_RIGHTS. [1]

토론도 참조하세요여기clone()Linux에서 이 문제를 "수정"하려는 최근 노력 에는 PID 대신 pid-fd를 반환하도록 플래그를 추가하는 것이 포함됩니다 .

그러나 그럼에도 불구하고 셀프 파이프라인 해킹[2]이나 더 나은 인터페이스가 필요하지 않은 것은 아닙니다. 왜냐하면 상위 프로세스에 하위 프로세스의 상태를 알리는 신호가 프로세스에서 처리하려는 유일한 신호가 아니기 때문입니다. 프로그램의 메인 루프. 불행하게도 epoll(7) + signalfd(2)Linux나 BSD kqueue(2)에서는 표준이 아닙니다 .기준인터페이스(이전 시스템에서는 지원되지 않음)가 열악합니다 pselect(2).

[1] 시스템 호출이 반환될 때 PID가 재활용되는 것을 방지하고 반환 값을 사용하는 것은 최신 시스템에서 다음을 사용 waitpid()하여 가능할 수 있습니다.waitid(.., WNOWAIT)

[2] 나는 자신이 그것을 발명했다는 DJ Bernstein의 주장에 대해서는 언급하지 않겠습니다(생략해서 죄송합니다 ;-)).

답변4

요점은 파일 설명자 관찰을 기반으로 이벤트 루프 스타일 모델을 실행하는 프로그램이 많다는 것입니다.선택(2)/여론조사(2)/전자 여론조사(7). 그러나 역사적으로 하위 프로세스의 프로세스 상태 전환(예: 종료)을 포함하여 파일 설명자를 사용하여 알림을 받지 못한 다양한 이벤트가 있었습니다. 이러한 기타 이벤트(타이머 만료, 신호 및 동기화 이벤트(예: 세마포어 변경) 포함)는 별도로 처리해야 하므로 이벤트 루프 모델의 프로그래밍이 복잡해집니다.

Linux 개발은 지난 몇 년 동안 이 문제를 해결해 왔으며 이제 우리는signalfd(2)(파일 설명자에서 신호를 읽을 수 있게 만들기)eventfd(2)(핸들은 파일 설명자의 동기화 기본 요소입니다)타이머 fd_create(2)(파일 설명자를 통해 알림을 받는 타이머를 생성합니다.) 이 모든 것은 다음에 제공될 수 있는 파일 설명자를 생성합니다.선택(2)/여론조사(2)/전자 여론조사(7).

마지막으로 최신 버전의 Linux에는 프로세스 핸들 개념이 파일 설명자로 추가되었습니다. CLONE_PIDFD깃발클론3()파일 설명자가 핸들로 반환되는 하위 프로세스를 만드는 데 사용할 수 있습니다. 파일 설명자를 입력할 수도 있습니다.선택(2)/여론조사(2)/전자 여론조사(7)하위 프로세스가 종료되면 표시를 읽을 수 있습니다.

관련 정보