fork()프로세스 인 경우 하위 프로세스는 파일 설명자를 상속합니다. 문제는 왜인가?
내가 보기에 파일 설명자를 공유하는 것은 각 프로세스가 r/w 포인터의 위치를 추적하려고 할 때 골치아픈 일입니다.
이 디자인 결정이 내려진 이유는 무엇입니까?
답변1
쉘 조각을 고려하십시오.
{ somecmd; othercommand *.txt; } > outputfile
리디렉션이 시작되면 쉘이 outputfile한 번 열리고 파일 핸들을 에 전달하여 처리 somecmd합니다 . 그룹화를 고려하면 사용자는 두 명령의 출력이 모두 끝날 것이라고 예상할 것입니다. 이는 아마도 화면에 나타나는 것과 마찬가지로 정확할 것입니다. ( 그룹이 쉘 스크립트인 경우에도 상황은 동일합니다.)othercmdforkoutputfile{ }
파일 위치가 모든 프로세스에 대해 독립적인 경우 의 출력이 othercommand손상됩니다 somecmd. 파일 핸들의 위치가 재설정되면 쉘은 끝을 가리키는 핸들을 fork전달할 수 없습니다 (파일 핸들이 파일 핸들 뒤에 있기 때문입니다 ). 파이프를 사용하여 두 명령의 출력을 수집하고(어차피 위치 독립적임) 다른 프로그램에서 두 명령의 출력을 연결해야 합니다.othercommandoutputfilesomecmd
{ somecmd; othercommand *.txt } | cat > outputfile
답변2
POSIX이것은 추론을 설명합니다:
POSIX 프로그래머가 호출하는 데는 두 가지 이유가 있습니다.십자가(). 한 가지 이유는 동일한 프로그램 내에서 새로운 제어 스레드를 생성하는 것입니다(이는 원래 POSIX에서 새 프로세스를 생성함으로써만 가능했습니다). 또 다른 이유는 다른 프로그램을 실행하는 새 프로세스를 생성하는 것입니다. 후자의 경우 전화십자가()곧 전화를 받을게요.구현하다기능.
"가난한 사람의 스레드"로 사용되는 경우 fork()파일 설명자를 복사하는 것이 좋습니다. 이 사용 사례는 계속 지원되어야 하므로 기능은 그대로 유지됩니다.