socket sys (libc) 函数是否应该总是为相同的参数返回相同的结果？

Question

我正在编写一个 C# 应用程序，它基本上完成类似的工作列表。不过，我在移植时遇到了麻烦IOCTL调用.NET。我的意思是，到目前为止我编写的互操作代码（以使我的 .NET 应用程序能够调用此非托管系统代码）未成功执行 ioctl 调用，总是返回 -1 作为错误。我注意到，当我在 Linux 中的 Visual Studio Code 中调试 iwlist 时，我总是看到调用插座(2,2,0) 返回文件描述符 3。

从我的 C# 应用程序中使用完全相同的参数运行相同的调用 - 返回 200 及以上范围内的文件描述符。

由于 iwlist 进一步的 ioctl 调用将返回的套接字作为输入参数，我想知道这本身是否表明了我的问题。换句话说，当 iwlist 原始代码总是在套接字打开时获取文件描述符 3 而 C# 应用程序从不获取文件描述符 3 时，我是否应该期望我移植的 c# iwlist 代码能够运行？

来自文档：

成功调用返回的文件描述符将是当前未为进程打开的最小编号的文件描述符。

如果是这样，为什么在调试时我总是得到相同的文件描述符？

Answer 1

大多数返回新文件描述符的 POSIX 库函数都会分配未使用的最小描述符编号。一个值得注意的例外是dup2函数，其目的是将描述符复制到特定数字：dup2(old, new)returns new。

如果您编写一个循环，在其中socket使用某些参数进行调用以返回描述符，并且您使用close该描述符，并且没有其他线程分配或销毁描述符，则socket每次应该返回相同的描述符编号。

该数字每次都指不同的对象；它类似于重新使用已释放的内存分配。