Comments 8
Надеюсь, автор осознает, что этот способ — костыль? Много стремного: мало того, что Вы меняете таймаут сокету, которым не владеете, и не знаете, как он используется, так Вы еще не используете никаких способов синхронизации. Да и смысла в синхронизации-то нет, потому что Вы не владеете кодом, где этот сокет создается и где с ним работают.
То, что у Вас пока ни разу еще не сломалось при таком подходе, — это просто вопрос времени.
И, кстати, в примере не видно C++, чистое C.
Просто этот метод на данный момент — единственный известный мне, а теперь и вам.
Во-первых,
If a blocking receive call times out, the connection is in an indeterminate state and should be closed.
То есть, я так понимаю, это UB. Либо я неправильно понимаю SO_RCVTIMEO на MSDN?
Во-вторых, side-эффекты этого способа не очень предсказуемы. Это race condition как минимум. Я у себя легко его воспроизвёл.
Насчёт костыля: а сколько раз вам нужно было определить?
Если dll не совсем безумная и не передаёт вам то blocking, то non-blocking — то один раз посмотреть посредством костыля — вроде нормально (костыль не идёт в prodaction, оставшись в тулзе для внутреннего пользования).
Определение blocking-режима TCP-сокета под Windows