Czy przed zamknięciem należy zamknąć deskryptory plików?

Question

Oczywiście, natychmiastową odpowiedzią dla większości sytuacji jest "tak" i jestem głęboko przekonany, że proces powinien poprawnie oczyścić wszelkie zasoby, które przeznaczył, ale to, co mam w mojej sytuacji, to długo działający demon systemu która otwiera ustaloną liczbę deskryptorów plików przy starcie i zamyka je wszystkie przed wyjściem.

Jest to osadzona platforma i staram się, aby kod był jak najbardziej kompaktowy, nie wprowadzając żadnego złego stylu. Ale ponieważ deskryptory plików są zamykane przed zakończeniem, czy ten kod czyszczenia deskryptora pliku służy w jakimkolwiek celu? Czy zawsze zamykasz wszystkie swoje deskryptory plików?

Answer 1

Zamknięcie deskryptorów plików po zakończeniu ich używania powoduje, że kod jest bardziej przydatny do wielokrotnego użytku i łatwiejszy do przedłużenia. To brzmi dla mnie jak przypadek, w którym masz ważny powód, by pozwolić im się zamknąć automatycznie.

Answer 2

man 3 exit:

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

więc wierzę pozostawiając główną skutecznie wywołuje funkcję wyjścia z głównej na wartości zwracanej. Chociaż twierdzę, że to zły styl. Osobiście I zawsze jawnie wolne/zamknąć wszelkie nabyte zasoby.

Answer 3

W pięknym świecie wbudowanych platform naprawdę trudno powiedzieć, co by się stało. Jednak gdybym był w twojej sytuacji, po prostu ręcznie przetestowałbym, czy ID pliku jest naprawdę wydany. A jeśli miejsce jest tak ważne, może udokumentujesz ten fakt w innym miejscu.

Answer 4

Tak, zamknij deskryptory plików i uwolnij całą pamięć sterty, nawet jeśli wiesz, że system operacyjny ją wyczyści - w ten sposób, gdy uruchomisz program valgrind lub podobne narzędzie, nie dostaniesz dużo hałasu w wyniki, i można łatwo rozpoznać "legit" wycieki fd.

Answer 5

Jedną z obaw, którą chciałbym mieć w związku z pozostawieniem zamykania deskryptorów plików na automatyczne czyszczenie, byłoby to, jak bardzo zależy ci na wszystkich danych, które zapisałeś w deskryptorach plików i czy możesz poradzić sobie z awarią pisać.

write() nie musi blokować (w zależności od tego, jak było otwarte() w pierwszej kolejności) i czekać na pomyślne zatwierdzenie danych, więc zdarzają się przypadki, gdy zamknięcie może się nie powieść, ponieważ podsystem podstawowy nie zatwierdził oczekujący zapis, a więc bliskie wyjście z awarią i ustawia errno na EIO, i w zależności od tego, co właśnie napisałeś, możesz lub nie chcesz podjąć działań naprawczych.

To jest narożny przypadek, w którym NAPRAWDĘ interesuje się spójnością danych, tj. Aplikacjami typu DBMS lub raportowaniem powodzenia/niepowodzenia kopii zapasowej. W wielu (większości?) Przypadkach tak naprawdę nie ma to większego znaczenia, a wszystko będzie w porządku, pozostawiając close(), aby przetworzyć czyszczenie/wyjście.