为什么调用closesock后socket接受函数没有释放？答案

【问题标题】：Why does the socket accept function not release after closesock called?为什么调用closesock后socket接受函数没有释放？
【发布时间】：2011-05-02 13:06:33
【问题描述】：

我有一个服务器应用程序，它打开一个套接字并监听一个连接。在应用程序中，我有一个单独的线程，它创建一个套接字、绑定它并在其上调用监听和接受函数。

当应用程序关闭时，我在创建的套接字上调用 closesocket，然后等待套接字线程关闭。但是，如果线程正在等待接受函数，则线程永远不会完成。

我认为在调用 cloasesocket 后，accept 函数会返回。这是一个正确的想法吗？如果是这样，为什么接受函数不返回？还有其他方法可以让accept函数返回吗？

【问题讨论】：

您需要发布closesocket 逻辑和accept 线程的代码以获得正确答案。
哪个平台。它在 Windows 上。这个类似问题的答案可能会有所帮助：stackoverflow.com/questions/2486335/…
Steve，感谢您的输入，但我正在谈论的代码嵌入在一个更大的应用程序中，因此我必须编写一个示例。我会看看我是否可以在周末。
伦，谢谢您的回复。我已经查看了你给我的来源......我仍在努力解决它。

标签： c++ sockets

【解决方案1】：

不要打电话给accept，除非select 说没关系。在这种情况下，accept 永远不会阻塞。

【讨论】：

使用了带计时器的选择功能，但由于某种原因，当应用程序关闭时，选择功能永远不会超时。任何想法为什么？
解决这个问题的正确方法不是立即关闭应用程序，而是以某种方式指示所有线程完成，等待它们完成，然后关闭。
select 无限期阻塞而不是accept 会不会一样？
select 具有超时参数，因此您可以在循环中调用它并使用您喜欢的超时。

【解决方案2】：

查看手册页...http://linux.die.net/man/2/accept

accept()阻塞socket A，当有新连接进来时，返回一个新的socket B连接客户端。这通常是一个紧密的循环，使用 fork() 和 exec() 将新连接发送到子进程以处理连接，而父进程返回到 accept() 以等待另一个连接。

你是想说程序中的另一个线程在 accept() 调用下关闭了套接字 A 吗？

【讨论】：

应用程序线程启动套接字服务器线程，应用程序线程停止套接字服务器线程。如果套接字服务器线程处于接受函数中，则线程不会结束。所以 Socket A 被应用程序线程关闭。我认为通过这样做，accept 函数会返回一个错误，从而允许套接字服务器线程结束。假设不正确？感谢您的评论。

【解决方案3】：

我遇到过类似的问题，即对 WSAStartup 和 WSACleanup 的调用不平衡。

程序在调用closesocket 之前调用了WSACleanup。试图关闭套接字的线程都将阻塞。当我删除“额外”WSACleanup 时，情况有所改善。

在其他地方，它说调用 WSACleanup 会释放对 accept 的调用，但会出现错误，但我不确定这是不是真的......如果你无法匹配那些启动和清理，谁知道还会出现什么问题功能。

【讨论】：