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

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

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

Ответ 1

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

Ответ 2

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

Ответ 3

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

Ответ 4

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

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

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

Ответ 5

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

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

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