如何确定文件描述符是否已经关闭？
在投票结束之前，请阅读，我知道存在类似的问题（：
这是我的情况 - 我有一个多线程的应用程序。所以，假设我有 10 个线程。所有这些都从同一个文件描述符读取（它是在一种非常罕见的情况下，当发生严重错误时，套接字应该被其中一个线程关闭。套接字的关闭有失败，执行 _Exit( FAILURE ) （我知道，这听起来像是代码中的糟糕设计或问题，但实际上并非如此，因为这是由非开源第三方引起的lib，有一个错误）。
这就是问题情况 - 他们可能都尝试同时关闭套接字，但其他人无法关闭它。 （shutdown 返回 -1，因为套接字已经关闭）并且执行了错误的 _Exit( FAILURE ) ，这
显然会破坏一切，我需要额外的检查 - 如果。套接字已经关闭（可能所有线程由于某种原因未能关闭套接字，然后至少有一个线程必须执行_Exit，这就是为什么检查shutdown的返回码代码> 不是 足够的）。
好吧，我发现了这个问题，它看起来这正是我想做的。 但我知道，任何类型的系统调用都需要时间（当然），并且套接字何时关闭取决于操作系统。
这是问题 - 如果套接字已经关闭或由于某种原因无法关闭，我该如何区分？ fcntl 能否向我保证，如果一个线程关闭了套接字，同时如果其他线程尝试关闭 套接字，它将失败，然后，如果我进行此检查（使用 fcntl ），这对我有用吗？
我还看到了其他答案，例如：“您可以使用 select 或 poll”，但它们仍然是系统调用，我不知道它们是否是更好的选择。我也不知道到底如何使用它们，但我想这没什么大不了的。
谢谢！
我还可以检查 shutdown 设置的 errno，但是“已连接”是什么意思？ “已连接”和“不是有效的描述符”之间有什么区别
ENOTCONN
The specified socket is not connected.
另外，令我困扰的是，我试图关闭的 FD 可能是无效的，因为我从 /proc/net 中获取它/tcp 与 proc/PID/fd 映射，我不知道是否所有文件都会像这样，它们在我的操作系统上看起来（操作系统肯定是 RHEL4 或 RHEL5） ，如果这很重要的话）
哦！它太长了，但我无法用更短的时间来解释它。
Before voting to close, please read, I know that there are similar questions (:
Here's my situation - I have an application, that is multithreaded. So, lets say I have 10 threads. All of them read from the same file descriptor (it's actually a socket ). And in a very rare situation, when a critical error occurs, the socket should be shutdown by one of the threads. The thing is, that any of these thread can do this. If the closing of the socket has failed, _Exit( FAILURE ) is executed (I know, that this sounds like an awful design or problem in the code, but it actually isn't, as this is caused by a non-opensource 3rd party lib, that has a bug).
And here's the problem situation - it's possible all of them to try to shutdown the socket in the same time. And one closes it, but the others cannot close it (shutdown returns -1, as the socket is already closed) and the bad _Exit( FAILURE ) is executed and that ruins everything.
Obviously, I need an additional check - if the socket is already closed (it's possible all threads to have failed shutting down the socket for some reason, and then at least one must execute _Exit, that's why checking the return code of shutdown is not enough).
Well, I found this question and it looks like that's exactly what I'm trying to do.
But I know, that any kind of system calls take time (of course ) and it's OS dependent when exactly the socket will be closed.
And here's the question - how can I make difference if a socket is already closed or it cannot be closed for some reason? Will the fcntl ensure me, that if one thread has closed the socket and at the same time if other thread try to shutdown the socket, it will fail and then, if I make this check ( with fcntl ), this will work for me?
I also saw the other answers like: "you can use select or poll", but they are still system calls and I don't know if they will be the better choice. I also don't know how exactly to use them, but it's not a big deal, I guess.
Thanks!
I can also check the errno set by shutdown, but what does "connected" mean? And what is the difference between "connected" and "not a valid descriptor"
ENOTCONN
The specified socket is not connected.
Also, what bothers me is, that the FD, I'm trying to close, could be invalid, as I take it from /proc/net/tcp mapped with proc/PID/fd and I don't know if all files will look like the way, they look on my OS (the OS will be for sure RHEL4 or RHEL5, if that matters)
Doh! It's damn long, but I can't explain it shorter.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
我假设您是说您的应用程序在关闭套接字后可以合理地继续吗？
似乎更好的方法是让一个中介线程从任何工作线程获取套接字关闭请求的通知，通知其他线程套接字现在已死亡，并负责关闭套接字本身。这消除了对失败原因的担忧，因为这一切都是在单个线程中处理的。
I assume you're saying it's possible for your application to reasonably continue after shutting down the socket?
It seems that a better approach would be to have a mediator thread that gets notified of socket close requests from any of the worker threads, notifies the other threads that the socket is now dead, and takes care of closing the socket itself. This eliminates the worries about the reason for failure because it's all handled in a single thread.
每当您的资源被多个线程使用并且可能被其中一个线程释放时，您必须使用锁保护所有访问。否则你将会遇到危险的竞争条件。我将在包含文件描述符的
int上使用读写锁。任何想要使用 fd 的线程都应该在使用期间持有读锁，并且任何想要更改 fd 变量的线程（例如关闭它并将其替换为 -1 以防止进一步使用）应该持有写锁。基本上，这与动态分配内存和
free的使用相同。Whenever you have a resource that's being used by more than one thread and which could be deallocated by one of them, you must protect all access with locks. Otherwise you will have dangerous race conditions. I would use a read-write lock on the
intcontaining the file descriptor. Any thread wanting to use the fd should hold a read lock for the duration it uses it, and any thread wanting to change the fd variable (e.g.closeit and replace it with -1 to prevent further use) should hold a write lock.Basically this is the same as use of dynamically allocated memory and
free.检查
errno是迄今为止最好的选择。从shutdown(2)我可以看到：EBADFs 不是有效的描述符ENOTCONN指定的套接字未连接ENOTSOCKs 是一个文件，而不是一个套接字。我的看法是：
EBADF意味着它已经关闭，ENOCONN意味着这个描述符后面没有连接（不是三向握手和所有那些爵士乐）。找出答案的最佳方法：在调用
shutdown失败后执行perror(3)并查看其内容。干杯
Checking the
errnois by far your best option. Fromshutdown(2)I can see:EBADFs is not a valid descriptorENOTCONNThe specified socket is not connectedENOTSOCKs is a file, not a socket.The way I see it:
EBADFmeans it has already been closed andENOCONNmeans there is not connection behind this descriptor (not three way handshake and all that jazz).Best way to find out: do a
perror(3)after the call toshutdownfails and see what it says.Cheers
您是否考虑过使用互斥体来保护套接字的关闭？通过使用其中之一，您可以确保只有一个线程尝试关闭套接字。您必须进行一些系统调用，即初始化时的
pthread_mutex_init和实际关闭套接字之前的pthread_mutex_trylock。然而，这些调用应该进行优化以获得快速回报。另一种避免系统调用的方法是自己实现互斥锁，这样只有一个线程实际上可以关闭套接字。当然，您必须调整现有的互斥算法之一，以便以后的线程不会等待，而是继续执行。
Have you thought of protecting the closing of the socket with a mutex? By using one of those you could make sure that only one thread tries to close the socket at all. You would have to make some systemcalls, namely
pthread_mutex_initon initialization andpthread_mutex_trylockbefore actually closing the socket. However, these calls should be optimized for fast returns.Another approach that avoids systemcalls would be to implement a mutex yourself, so that only one of the threads actually gets to close the socket. Of course you would have to adapt one of the existing algorithms for mutual exclusion so that the later threads do not wait, but simply continue execution.
正确的答案是 R.. 处理线程问题。回复问题“如何找出 fd 的状态？”：
fstat()Per POSIX:
如果文件描述符或套接字出现任何问题，它将返回 -1。在已关闭的文件描述符或套接字上，
errno将设置为EBADF。 stat 系列调用专门用于测试：文件 (stat)、链接 (lstat) 和文件描述符 (fstat)。其他调用，如
close和shutdown也会在已经关闭的 fd 上返回错误。但它们的目的是其他的，并且测试已连接的套接字是一个副作用。发布是因为提到的其他系统调用并不是为了测试文件描述符。我读到的原始问题的一部分。
The correct answer was by R.. which dealt with threading problems. Reply to the question 'how to find out the status of an fd?':
fstat()Per POSIX:
It will return -1 on any problem with a file descriptor or socket.
errnowill be set toEBADFon a file descriptor or socket that is already closed. the stat family of calls is specifically meant to test: files (stat), links(lstat) and file descriptors (fstat).Other calls like
closeandshutdownalso do return errors on already closed fd's. But their purpose is something else, and testing for a connected socket is a side effect.Posted because the other syscalls mentioned are not meant to test file descriptors. Part of the original question as I read it.