fork ()가 파일 디스크립터를 리턴하도록 설계된 이유는 무엇입니까?

자신에 대한 웹 페이지 자기 파이프 트릭 , 댄 번스타인은 경쟁과 조건에 대해 설명 select()하고 신호를 제공하는 해결 방법을하고 있다는 결론

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

그는 이것이 의미하는 바는- select()상태 변경에 대한 알림을 받기 위해 신호 처리기를 사용하지 않고 자식 프로세스에서 상태 변경을 처리 할 수 있다는 것 입니까?

문제는 소스에 설명되어 있으며 select()와 같은 신호로 중단되어야 SIGCHLD하지만 경우에 따라 제대로 작동하지 않습니다. 따라서 해결 방법은 파이프에 신호 쓰기를하는 것 select()입니다. 파일 디스크립터를 보는 select()것이 문제이므로 문제를 해결할 수 있습니다.

이 해결 방법은 기본적으로 신호 이벤트를 파일 디스크립터 이벤트로 바꿉니다. 경우 fork()단지 첫 번째 장소에서 FD를 반환하는 FD가 다음 아마도 직접 사용될 수로, 해결 방법은 필요하지 않을 것입니다 select().

예, 마지막 단락의 설명은 나에게 맞는 것 같습니다.

fd (또는 다른 종류의 커널 핸들)가 일반 프로세스 ID 번호보다 나은 또 다른 이유는 프로세스가 종료 된 후 PID가 재사용 될 수 있기 때문입니다. 프로세스에 신호를 보낼 때 문제가 될 수 있습니다. 프로세스가 자신이 생각하는 프로세스인지, 동일한 PID를 재사용하는 프로세스가 아닌지 확실하지 않을 수 있습니다. ( wait()PID를 해제 하려면 부모가 자식 을 실행해야하기 때문에 자식 프로세스에 신호를 보낼 때 이것이 문제가되지 않는다고 생각합니다 .)

"유닉스와 다른 방식으로 디자인하면 좋을 것"이라고 생각합니다.

PID의 문제점은 다른 프로세스에 재사용 할 수있는 글로벌 네임 스페이스에 있으며, fork()항상 자식 프로세스를 참조하도록 보장되는 어떤 종류의 핸들을 부모에 반환 하면 좋을 것입니다. 상속 또는 유닉스 소켓 / SCM_RIGHTS[1]을 통해 다른 프로세스로 전달할 수 있습니다.

PID 대신 pid-fd를 리턴하는 플래그를 추가하는 것을 포함하여 Linux에서이를 수정하기위한 최근의 노력에 대해서는 여기 에서 논의를 참조하십시오 clone().

그러나 부모 프로세스에 자식의 상태를 알리는 신호가 메인 루프에서 처리하려는 유일한 신호가 아니기 때문에 자체 파이프 해킹 [2] 또는 더 나은 인터페이스가 필요하지 않습니다. 프로그램의. 불행히도 epoll(7) + signalfd(2)Linux 또는 kqueue(2)BSD 와 같은 것은 표준이 아니며, 유일한 표준 인터페이스 (이전 시스템에서는 지원되지 않음)가 훨씬 열등 pselect(2)합니다.

[1] waitpid()syscall이 리턴되고 리턴 값이 사용 된 시간까지 PID가 재순환되는 것을 막는 것은 아마도 새로운 시스템에서 waitid(.., WNOWAIT)대신 에 사용함으로써 달성 될 수 있습니다 .

[2] 나는 그가 그것을 발명했다고 DJ 번스타인의 주장에 대해서는 언급하지 않을 것이다.

Bernstein은이 "Right Thing"설명에 대해 많은 맥락을 제시하지는 않지만 추측 할 수 있습니다. fork (2)가 PID를 반환하면 open (2), creat (2) 등이 파일 설명자를 반환하는 것과 일치하지 않습니다. 나머지 유닉스 시스템은 PID 대신 프로세스를 나타내는 파일 디스크립터를 사용하여 프로세스 조작을 수행했을 수 있습니다. 시스템 호출 signalfd (2) 가 존재하는데, 이는 신호와 파일 디스크립터 사이에서 다소 더 나은 상호 작용을 허용하며 프로세스를 나타내는 파일 디스크립터가 작동 할 수 있음을 보여줍니다.