当然,大多数情况下的直接答案是"是",我坚信一个进程应该正确清理它已经分配的任何资源,但我在我的情况下拥有的是一个长期运行的系统守护进程,它打开一个固定的启动时的文件描述符数量,并在退出前将它们全部关闭.
这是一个嵌入式平台,我正在努力使代码尽可能紧凑,同时不引入任何不良风格.但是,由于文件描述符无论如何都会在退出之前关闭,这个文件描述符清理代码是否可以用于任何目的?你总是关闭所有文件描述符吗?
完成使用后关闭文件描述符可使代码更易于重用且更易于扩展.这听起来像是一个你有正当理由让它们自动关闭的情况.
在嵌入式平台的美丽世界中,很难说会发生什么.但是,如果我在你的情况下,我只是手动测试以查看文件ID是否真的被释放..而且,如果空间很重要,也许你可以在其他地方记录这个事实.
是的,关闭你的文件描述符并释放所有堆内存,即使你知道操作系统会清理它 - 这样,当你运行valgrind或类似的工具时,你不会在结果中得到很多噪音,并且你可以轻松识别"合法"的fd泄漏.
关于将文件描述符关闭到自动清理方面,我将关注的一个问题是你关心你写入文件描述符的任何数据,以及你是否合理地处理了写入失败.
write()不需要阻塞(取决于它在第一时间是如何打开),并等待数据成功提交,因此有些情况下close可能会失败,因为底层子系统无法提交挂起的写入,因此关闭退出失败并将错误设置为EIO,并且根据您刚刚写的内容,您可能会或可能不想采取一些纠正措施.
不可否认,这是一个极端情况,您真正关心数据一致性,即DBMS类型的应用程序或报告备份的成功/失败.在许多(大多数?)情况下,它并没有那么重要,你可以很好地离开close()来处理清理/退出.