正如我不断发现的那样,文件描述符有很多种--几乎所有的东西都是围绕文件描述符抽象的:常规文件、套接字、信号和计时器(例如)。所有文件描述符都只是整数。
给定一个文件描述符,是否有可能知道它是什么类型?例如,最好有一个系统调用,如getFdType(fd)。
如果一个epoll_wait由于多个文件描述符准备就绪而被唤醒,那么每个文件描述符的处理将基于其类型。这就是我需要这种类型的原因。
当然,我可以自己单独维护这些信息,但是让系统支持它会更方便。
而且,所有的文件描述符,不管类型如何,都是顺序的。我的意思是,如果打开一个常规数据文件,然后创建一个计时器文件描述符,然后创建一个信号文件描述符,它们是否都保证按顺序编号?
发布于 2020-02-26 05:07:33
正如“另一个人”所提到的,最明显的这种呼吁就是fstat。st_mode成员包含用于区分常规文件、设备、套接字、管道等的位。
但在实践中,您几乎肯定需要跟踪您自己的fd是哪一个。当您打开几个不同的常规文件时,知道它是一个常规文件并不会有太大帮助。因此,既然您必须在代码中的某个地方维护这些信息,那么返回到该记录似乎是最健壮的方法。
(在程序中检查一些变量也比进行一个或几个额外的系统调用要快得多。)
也是所有文件描述符,不管类型如何,都是顺序的。我的意思是,如果打开一个常规数据文件,然后创建一个计时器文件描述符,然后创建一个信号文件描述符,它们是否都保证按顺序编号?
不怎么有意思。
据我所知,创建新fd的调用总是返回编号最低的可用fd。有一些老程序依赖于这种行为;在dup2存在之前,我认为将标准输入转移到新文件的公认方法是close(0); open("myfile", ...);。
然而,很难真正确定fds是可用的。例如,用户可能已经以/usr/bin/prog 5>/some/file/somewhere的身份运行了您的程序,然后看起来fd 5被跳过了,因为fd 5上已经打开了/some/file/somewhere,因此,如果您连续打开一堆文件,您就不能确定您将得到顺序的fds,除非您自己已经关闭了所有fds,并且确信所有低编号的fds已经在使用中。这样做似乎更麻烦(和潜在问题的根源),而不仅仅是跟踪fds在一开始。
https://stackoverflow.com/questions/60400581
复制相似问题