是否有系统调用或某种方式可以知道Linux中文件描述符的类型（例如，常规文件fd、套接字fd、信号fd、计时器fd）？

正如我不断发现的，有各种各样的文件描述符——几乎所有的东西都是围绕一个文件描述符抽象的：常规文件、套接字、信号和计时器（例如）。所有文件描述符都只是整数

给定一个文件描述符，是否可以知道它是什么类型？例如，最好有一个系统调用，比如getFdType（fd）

如果由于多个文件描述符准备就绪而唤醒epoll_wait，则每个文件描述符的处理将基于其类型。这就是我需要这种类型的原因

当然，我可以自己单独维护这些信息，但让系统支持会更方便

此外，所有文件描述符（无论类型如何）都是顺序的。我的意思是，如果你打开一个常规数据文件，然后创建一个计时器文件描述符，然后创建一个信号文件描述符，它们都保证按顺序编号吗？

正如“另一个人”所提到的，最明显的这种调用是

fstat

。

st_mode

成员包含用于区分常规文件、设备、套接字、管道等的位

但在实践中，您几乎肯定需要跟踪自己的fd是哪个。当您打开多个不同的常规文件时，知道它是一个常规文件并没有多大帮助。因此，既然您必须在代码中的某个地方维护这些信息，那么引用该记录似乎是最可靠的方法

---

（检查程序中的一些变量也将比执行一个或多个额外的系统调用快得多。）

此外，所有文件描述符（无论类型如何）都是顺序的。我的意思是，如果你打开一个常规数据文件，然后创建一个计时器文件描述符，然后创建一个信号文件描述符，它们都保证按顺序编号吗

不是真的

据我所知，创建新fd的调用将始终返回编号最低的可用fd。有一些老程序依赖于这种行为；在

dup2

存在之前，我认为将标准输入移动到新文件的公认方法是

close（0）；打开（“myfile”，…）

然而，很难真正确定哪些FD可用。例如，用户可能以
/usr/bin/prog 5>/some/file/somewhere
的身份运行您的程序，然后会显示fd 5被跳过，因为fd 5上已经打开了
/some/file/somewhere
。因此，如果您连续打开一组文件，则无法真正确定是否会获得连续的FD，除非您自己刚刚关闭了所有这些FD，并且确定所有编号较低的FD都已在使用。这样做似乎比一开始就跟踪FD更麻烦（也是潜在问题的根源）。
最好询问，例如，检查任意FD是否有调试/分析原因，而不是将其用于epoll决策，因为这是一个限制性的设计决策和架构死胡同。好吧，没有什么比
getFdType
更好的了，但是传统上有
fstat
来区分类似文件的类型，并尝试使用特定于fd的调用，如
getsockopt
或
timerfd\u gettime
来区分这些类型，作为最后的手段，
/proc/1234/fd/42上的
readlink
，以获取一个描述性字符串，如
anon\u inode:[timerfd]
这是fstat调用@另一个家伙“…因为这是一个限制性的设计决定和建筑死胡同。”你能详细说明一下吗？如果需要，我对体系结构的更改持开放态度。大多数服务器无论如何都需要每个FD的附加上下文和元数据，例如其当前特定于协议的状态/标志、发送/接收队列或位置、水印/重试信息等@我已经解决了这方面的问题。我的fdData结构维护这些信息。我认为Nate的观察结果是，如果有系统调用的话，使用系统调用会很昂贵，这是我没有想到的。”（检查程序中的一些变量也会比进行一次或多次额外的系统调用快得多。）“IMHO是你答案中的关键点。嗯，我不想做太多，因为在许多程序中，无论哪种方式，它都只占总执行时间的很小一部分。但我想我应该加入一些东西来吸引那些无法抗拒不必要的优化的人；-）