종료하기 전에 파일 설명자를 닫아야 합니까?

Question

물론 대부분의 상황에 대한 즉각적인 대답은 다음과 같습니다. "예", 저는 프로세스가 할당한 모든 리소스를 올바르게 정리해야 한다고 굳게 믿습니다. 하지만 제 상황에서는 시작 시 고정된 수의 파일 설명자를 열고 그 전에 모두 닫는 장기 실행 시스템 데몬이 있습니다. 종료.

이것은 임베디드 플랫폼이고 나쁜 스타일을 도입하지 않으면서 코드를 가능한 한 간결하게 만들려고 노력하고 있습니다.그러나 파일 설명자는 어쨌든 종료 전에 닫히므로 이 파일 설명자 정리 코드가 어떤 용도로 사용됩니까?항상 모든 파일 설명자를 닫습니까?

Answer 1

파일 설명자를 닫는 경우 사용을 완료하면 코드가 더 재사용 가능하고 확장하기가 더 쉬워집니다. 이것은 당신이 자동으로 폐쇄 할 수있는 유효한 이유가있는 경우처럼 들립니다.

Answer 2

예, OS가 정리할 것이라는 것을 알고 있더라도 파일 설명자를 닫고 모든 힙 메모리를 비우십시오. 이렇게 하면 valgrind 또는 유사한 도구를 실행할 때 결과에 ​​많은 노이즈가 발생하지 않습니다. "합법적인" fd 누출을 쉽게 인식할 수 있습니다.

Answer 3

내장 플랫폼의 아름다운 세계에서는 무슨 일이 일어날 지 말하기가 어렵습니다. 그러나 내가 당신의 상황에 처해 있다면, 파일 ID가 실제로 릴리스되었는지 확인하기 위해 수동으로 테스트합니다. 그리고 공간이 중요하다면 다른 곳 에서이 사실을 문서화 할 수 있습니다.

Answer 4

파일 설명자를 자동 정리에 맡기는 것과 관련하여 내가 가질 수 있는 한 가지 우려 사항은 해당 파일 설명자에 작성한 데이터에 대해 얼마나 관심을 갖고 있는지, 그리고 쓰기 실패를 합리적으로 처리할 수 있는지 여부입니다.

write()는 차단할 필요가 없으며(처음에 어떻게 open()되었는지에 따라) 데이터가 성공적으로 커밋될 때까지 기다릴 필요가 없습니다. 따라서 기본 하위 시스템이 보류 중인 쓰기 커밋에 실패하여 닫기가 실패할 수 있는 경우가 있습니다. 따라서 실패로 종료를 닫고 errno를 EIO로 설정합니다. 방금 작성한 내용에 따라 수정 조치를 취할 수도 있고 원하지 않을 수도 있습니다.

물론 이는 데이터 일관성에 정말로 신경을 쓰는 코너 케이스입니다.DBMS 유형 애플리케이션 또는 백업 성공/실패를 보고합니다.많은(대부분의?) 경우에는 그다지 중요하지 않으며 정리/종료를 처리하기 위해 close()를 생략해도 괜찮습니다.

Answer 5

Man 3 출구 :

....
All open stdio(3) streams are flushed and closed.  Files created by tmpfile(3) are removed.

그래서 나는 메인을 떠나는 것이 메인의 반환 값으로 출구 함수를 효과적으로 호출한다고 생각합니다. 비록 나는 그것이 나쁜 스타일이라고 주장하지만. 개인적으로, 나는 언제나 획득 한 자원을 명시 적으로 자유롭게 무료/닫습니다.