Нужно ли закрывать файловые дескрипторы перед выходом?
конечно, немедленный ответ для большинства ситуаций -"да", и я твердо верю, что процесс должен правильно очистить любые ресурсы, которые он выделил, но то, что у меня есть в моей ситуации,-это долгосрочный системный демон, который открывает фиксированное количество файловых дескрипторов при запуске и закрывает их все перед выходом.
это встроенная платформа, и я пытаюсь сделать код максимально компактным, не вводя при этом никакого плохого стиля. Но так дескрипторы файлов закрываются перед выходом в любом случае, служит ли этот код очистки дескриптора файла какой-либо цели? Вы всегда закрываете все свои файловые дескрипторы?
5 ответов
закрытие дескрипторов файлов, когда вы закончите их использование, сделает ваш код более многоразовым и простым в расширении. Это звучит для меня как случай, когда у вас есть веская причина позволить им закрыться автоматически.
да, закройте файловые дескрипторы и освободите всю память кучи, даже если вы знаете, что ОС очистит ее - таким образом, когда вы запускаете valgrind или какой-то аналогичный инструмент, вы не получаете много шума в результатах, и вы можете легко распознать "законные" утечки fd.
в прекрасном мире встроенной платформы очень трудно сказать, что произойдет. Однако, если бы я был в вашей ситуации, я бы просто вручную проверил, действительно ли выпущен идентификатор файла.. И, если пространство так важно, может быть, вы могли бы документировать этот факт в другом месте.
единственное, что меня беспокоит в отношении того, чтобы оставить закрытие дескрипторов файлов для автоматической очистки, было бы то, насколько вы заботитесь о любых данных, которые вы написали в указанные дескрипторы файлов, и если вы разумно можете справиться с сбоем записи.
write() не нужно блокировать (в зависимости от того, как он был открыт()ed в первую очередь) и ждать успешной фиксации данных, поэтому есть случаи, когда close может завершиться ошибкой, потому что базовая подсистема не может зафиксировать ожидающую запись, и, таким образом, закройте выходы с ошибкой и установите errno в EIO, и в зависимости от того, что вы только что написали, вы можете или не хотите предпринимать какие-то корректирующие действия.
по общему признанию, это угловой случай, когда вы действительно заботитесь о согласованности данных, т. е. о приложениях типа СУБД или об успешности/сбое резервного копирования. Во многих (большинство?) случаи это не имеет большого значения, и вы будете в порядке, оставив close () для обработки очистки/выхода.
человек 3 выхода:
....
All open stdio(3) streams are flushed and closed. Files created by tmpfile(3) are removed.
поэтому я считаю, что оставляя main эффективно вызывает функцию выхода с возвращаемым значением main. Хотя я бы сказал, что это плохой стиль. Лично Я всегда явно освободить / закрыть любые приобретенные ресурсы.