Tim Rühsen wrote:
There has been commit 4a685764a845d5c74a76fcb49a4671f055b8d5f4 (15.5.2011) between release 1.12 and 1.13. It sets the socket to blocking after calling gnulib's select().
This has nothing to do with connect() hanging. select() comes into play later. Besides my patch to remove 'set_windows_fd_as_blocking_socket()' was voted down back then. I see the from the call-stack that connect() is hanging inside Gnulib: ... ntdll.dll!ZwWaitForSingleObject+0xc ntdll.dll!RtlInterlockedPushEntrySList+0x32b ntdll.dll!RtlInterlockedPushEntrySList+0x355 ntdll.dll!RtlResetNtUserPfn+0x3f wget.exe!close_fd_maybe_socket+0x36 wget.exe!execute_close_hooks+0x30 wget.exe!execute_all_close_hooks+0x17 wget.exe!rpl_close+0x12 wget.exe!connect_to_host+0x3ea wget.exe!gethttp+0x686 wget.exe!http_loop+0x430 wget.exe!retrieve_url+0x1cb .. And from the command 'wget -d --connect-timeout=4 http://192.0.2.1:12345/' + ^C: Setting --connect-timeout (connecttimeout) to 4 DEBUG output created by Wget 1.15.00 (09-March-2015) on Win-8.1. Build 9600 (MSVC). ... seconds 0.00, Connecting to 192.0.2.1:12345... seconds 4.00, So it seems the 'run_with_timeout()' used to connect works fine since the thread is not running. So it seems the Gnulib's close() is blocking for an unknown reason. -- --gv
