Почему Windows select () не всегда уведомляет select () потока B, когда поток A закрывает свой конец пары сокетов?

Просто для записи, эта проблема оказалась совершенно другой проблемой, не связанной с потоковой передачей, Windows или стандартным вводом. Фактическая проблема заключалась в взаимоблокировке между процессами, когда родительский процесс был заблокирован, ожидая завершения дочерних процессов, но иногда дочерние процессы блокировались одновременно, ожидая, пока родительский процесс предоставит им некоторые данные, и поэтому ничто не могло двигаться вперед.

Приносим извинения всем за то, что потратили время на отвлекающий маневр; если есть стандартный способ закрыть это дело как необоснованное, дайте мне знать, и я это сделаю.

-Джереми

Возможно ли у вас состояние гонки? Например. Вы гарантируете, что функция CreateConnectedSocketPair() определенно вернулась до того, как stdin-thread сможет попытаться закрыть свой сокет?

Я изучаю ваш код. В CreateConnectedSocketPair () socket1 используется для listen (), а newfd используется для отправки / получения данных. Итак, почему "socket1 = newfd"? Как тогда закрыть listenfd?

Не решение, но в качестве обходного пути, не могли бы вы отправить какое-то волшебное сообщение «stdin has closed» через TCP-сокет и заставить принимающую сторону отключать свой сокет, когда он это видит, и запускать любой обработчик «stdin has closed»?

Честно говоря, ваш код слишком длинный, и у меня сейчас нет времени на него тратить.

Скорее всего, проблема в некоторых случаях заключается в том, что закрытие сокета не приводит к плавному завершению работы (FIN).

Проверка исключений, возвращаемых из вашего выбора, может выявить остальные случаи. Существует также (небольшая) вероятность того, что в сокет не отправляется уведомление о том, что другой конец закрыт. В этом случае нет другого способа, кроме тайм-аутов или сообщений «keep alive» / ping между конечными точками, чтобы узнать, что сокет закрыт.

Если вы хотите точно выяснить, что происходит, отключите wirehark и поищите FIN и RST (и отсутствие чего-либо). Если вы видите правильную последовательность FIN, когда ваш сокет закрыт, значит, проблема в вашем коде. если вы видите RST, он может быть пойман исключениями, а если вы ничего не видите, вам нужно будет разработать способ в своем протоколе «пинговать» каждую сторону соединения, чтобы убедиться, что они все еще живы, или установить достаточно короткий тайм-аут для дополнительных данных.

Вместо того, чтобы преследовать предполагаемые ошибки в select (), я собираюсь обратиться к вашей первоначальной ошибке, которая оттолкнула вас от простого, надежного, однопоточного дизайна.

Вы сказали: «Вы также не можете выполнять неблокирующее чтение на STDIN_FILE_HANDLE. Это означает, что нет возможности читать стандартный ввод из основного потока, поскольку ReadFile () может блокироваться бесконечно», но это еще не все. Посмотрите на ReadConsoleInput, WSAEventSelect и WaitForMultipleObjects. Дескриптор stdin будет сигнализирован только тогда, когда есть ввод, и ReadConsoleInput вернется немедленно (почти такая же идея, как select () в Unix).

Или используйте ReadFileEx и WaitForMultipleObjectsEx, чтобы чтение консоли запускалось с APC (что не так уж и асинхронно, оно выполняется в основном потоке и только во время WaitForMultipleObjectsEx или другой явной функции ожидания).

Если вы хотите использовать второй поток для получения асинхронного ввода-вывода на stdin, вы можете попробовать закрыть переданный дескриптор для выбора вместо завершения работы сокета (через closesocket на другом конце). По моему опыту, select () имеет тенденцию возвращаться очень быстро, когда закрывается один из ожидающих файлов.

Или, может быть, ваша проблема в другом. В документах select говорится: «Для сокетов, ориентированных на соединение, удобочитаемость также может указывать на то, что запрос на закрытие сокета был получен от однорангового узла». Обычно вы отправляете этот «запрос на закрытие сокета», вызывая shutdown (), а не closesocket ().