c - 为什么当线程 A 关闭套接字对的末端时，windows select() 并不总是通知线程 B 的 select()？

Question

我在 Windows XP (SP3) 下遇到的情况让我抓狂，我已经快筋疲力尽了，所以也许有人可以提供一些灵感。

我有一个 C++ 网络程序(非 GUI)。该程序专为在 Windows、MacOS/X 和 Linux 下编译和运行而构建，因此它使用 select() 和非阻塞 I/O 作为其事件循环的基础。

除了其网络职责外，该程序还需要从标准输入读取文本命令，并在标准输入关闭时优雅地退出。在 Linux 和 MacOS/X 下，这很容易——我只需在我的读取 fd_set 中将 STDIN_FILENO 包含到 select() 中，然后当 stdin 关闭时 select() 返回。我检查 FD_ISSET(STDIN_FILENO, &readSet) 是否为真，尝试从 stdin 读取一些数据，recv() 返回 0/EOF，因此我退出进程。

另一方面，在 Windows 下，您不能选择 STDIN_FILE_HANDLE，因为它不是真正的套接字。您也不能对 STDIN_FILE_HANDLE 进行非阻塞读取。这意味着无法从主线程读取标准输入，因为 ReadFile() 可能会无限期阻塞，从而导致主线程停止提供其网络功能。

没问题，我说，我将生成一个线程来为我处理标准输入。该线程将在无限循环中运行，在 ReadFile(stdinHandle) 中阻塞，每当 ReadFile() 返回数据时，stdin 线程就会将该数据写入 TCP 套接字。该套接字连接的另一端将由主线程选择()打开，因此主线程将看到通过连接传入的标准输入数据，并以与在任何其他操作系统下相同的方式处理“标准输入”。如果 ReadFile() 返回 false 以指示标准输入已关闭，则标准输入线程将关闭其套接字对的末端，以便通过 select() 通知主线程，如上所述。

当然，Windows 没有很好的 socketpair() 函数，所以我不得不使用 listen()、connect() 和 accept() 自己动手(如 CreateConnectedSocketPair() 函数所示 here .但我这样做了，而且总的来说它似乎有效。

问题是它不是 100% 有效。特别是，如果 stdin 在程序启动后的几百毫秒内关闭，则大约有一半时间主线程不会收到有关套接字对的 stdin 端已关闭的任何通知。我的意思是，我可以看到(通过我的 printf()-调试)stdin-thread 在其套接字上调用了 closesocket()，并且我可以看到主线程正在关联的 select()-ing套接字(即套接字对的另一端)，但 select() 永远不会返回它应该返回的......如果它确实返回，由于其他一些套接字选择准备好进行任何操作，FD_ISSET(main_thread_socket_for_socket_pair，＆readSet)返回0，就好像连接没有关闭一样。

在这一点上，我唯一的假设是 Windows 的 select() 实现中存在一个错误，导致主线程的 select() 没有注意到套接字对的另一端已被标准输入关闭-线。还有其他解释吗？ (注意这个问题在Windows 7下也有报到，虽然我没有在那个平台上亲眼看过)

Answer 1

仅作记录，这个问题原来是一个完全不同的问题，与线程、Windows 或标准输入无关。实际问题是进程间死锁，父进程被阻塞，等待子进程退出，但有时子进程会同时被阻塞，等待父进程提供一些数据，所以什么都不会前进。

向所有人道歉，因为在一条红鲱鱼上浪费了你们的时间；如果有一种标准的方法可以将此案例视为无根据的结案，请告诉我，我会这样做。

-杰里米