DJ VK писал(а):если запущен процесс ожидания загрузки тайла, и тикает время до таймаута, то принудительно это ожидание не рвется.
Угу. Натыкался, да.
Иногда при подвисшем сокете (действительно подвисшем - например хидер с ненулевым Content-Length уже прошел, а данные так и не появились - и программа их ждет бесконечно и по таймауту иногда НЕ отваливается) - из программы выйти не удается никакими путями кроме как через три кнопки. При попытке штатного выхода - либо ничего не происходит (прога не реагирует на попытки выхода - счетчик времени тем не менее идет и программа не висит), либо при попытке выхода банально выдает AV еррор, а по его закрытии - возвращается опять в программу, и так по кругу. Сокет при этом висит под программой в состоянии TIME_WAIT, и может так висеть бесконечно.
Но это скорее даже не к программе наверное, а к широкоизвестной в узких кругах своеобразной обработке TIME_WAIT/TIME_WAIT2 в TCP/IP винды, на которые CLOSE_TIMEOUT почему-то в некоторых редких случаях не распространяется. Обычно это вылазит при сильной сетевой и многопротокольной нагрузке на\под данную винду. Вот, например:
- Код: Выделить всё
When you try to establish connection you should use timeouts as said in
RFC. Program uses socket's timeouts. Windows sockets have some differences in
"timeout API", but some compilers do not consider them fully as per RFC. So when you set
timeouts with BIO_ctrl() and BIO_CTRL_DGRAM_SET_RECV_TIMEOUT or
BIO_CTRL_DGRAM_SET_SEND_TIMEOUT it does not work properly.
If recv(...) or send(...) fails due to timeout WSAGetLastError() sometimes returns
WSAETIMEDOUT, but not EAGAIN. But the status checks for EAGAIN or v/v. So, for the event
this only timeout does not ever happen.
Привет Билли.
