Есть ли необходимость закрывать файловые дескрипторы перед выходом?

Question

Конечно, немедленный ответ для большинства ситуаций - " да " , и я твердо убежден в том, что процесс должен правильно очищать любые ресурсы, которые он выделил, но то, что у меня есть в моей ситуации это длительный системный демон, который при запуске открывает фиксированное количество файловых дескрипторов и закрывает их перед выходом.

Это встроенная платформа, и я пытаюсь сделать код максимально компактным, не вводя при этом никакого плохого стиля. Но поскольку файловые дескрипторы перед выходом закрываются, все равно, служит ли этот код очистки файлового дескриптора какой-либо цели? Вы всегда закрываете все свои файловые дескрипторы?

Answer 1

Закрытие файловых дескрипторов после их использования делает ваш код более пригодным для повторного использования и расширяемым. Для меня это звучит как случай, когда у вас есть веская причина, чтобы позволить им автоматически закрыться.

Answer 2

Да, закройте файловые дескрипторы и освободите всю кучную память, даже если вы знаете, что ОС очистит ее - таким образом, когда вы запускаете valgrind или какой-либо подобный инструмент, вы не получите много шума в результаты, и вы можете легко распознать "законный" утечки fd.

Answer 3

В прекрасном мире встраиваемых платформ очень сложно сказать, что произойдет. Однако, если бы я оказался в вашей ситуации, я бы просто вручную проверил, действительно ли идентификатор файла освобожден. И, если пространство так важно, возможно, вы могли бы задокументировать этот факт в другом месте.

Answer 4

Единственное, что мне хотелось бы оставить в связи с закрытием файловых дескрипторов для автоматической очистки, это то, насколько вы заботитесь о любых данных, которые вы записали в эти файловые дескрипторы, и можете ли вы разумно справиться с ошибкой писать.

write () не нужно блокировать (в зависимости от того, как он был открыт () в первую очередь) и ждать успешной фиксации данных, поэтому существуют случаи, когда закрытие может завершиться неудачей, поскольку базовая подсистема не может зафиксировать в ожидании записи и, таким образом, закрывает выходы с ошибкой и устанавливает errno в EIO, и в зависимости от того, что вы только что написали, вы можете или не можете предпринять некоторые корректирующие действия.

По общему признанию, это угловой случай, когда вы ДЕЙСТВИТЕЛЬНО заботитесь о согласованности данных, то есть о приложениях типа СУБД или сообщении об успехе / неудаче резервного копирования. Во многих (большинстве?) Случаях это на самом деле не имеет большого значения, и вы будете в порядке, если не будете использовать close () для очистки / выхода.

Answer 5

выход man 3:

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

Поэтому я считаю, что выход из main вызывает функцию выхода с возвращаемым значением main. Хотя я бы сказал, что это плохой стиль. Лично я всегда явно освобождаю / закрываю любые полученные ресурсы.