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

Question

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

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

Answer 1

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

Answer 2

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

Answer 3

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

Answer 4

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

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

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

Answer 5

человек 3, выход:

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

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