This is a good question. In the scheme I suggested, the worker thread (the
one that calls gethostbyname()) may indeed block if, as empirically noted by
the original poster, the network interface is down. The controller thread
(the one that spawns the worker) is blocked in a call to
WaitForSingleObject, but has provided the worker's thread handle as the
synchronization object to block on (the thread signals when it terminates by
natural, non-coerced means), and a timeout as a parameter. The way this
works is that the controller thread will be unblocked if timeout OR the
thread signals. Either way it is guaranteed to unblock on or before the
timeout provided to WaitForSingleObject expires. WaitForSingleObject returns
a value that is used to determine what caused it to unblock that can be
tested by the controller to determine if the timeout condition occurred. If
it did not, then we know that the worker successfully made the call to
gethostbyname(), and we are done. If timeout did occur, then the controller
is free to go about whatever business is needs to do with the knowledge that
the network interface is down. This leaves the worker thread hanging -
blocked for an unknown length of time. You are correct to point out the
dangers of TerminateThread and TerminateProcess. However, calling
TerminateThread on the worker has no undesirable consequences that I'm aware
of. Sure it might result in a messy death. But the network interface is
hosed. You can't hose it any further than infinitely blocking standard API
calls. So go ahead and pull the trigger and call TerminateThread. Any
unclaimed stack will be reclaimed by the operating when the process exits.
The network interface needs to be re-initialized anyway in this case so why
worry about it? Do you follow the logic here?

----- Original Message -----
From: "Alexander J. Oss" <alexoss_at_verizon.net>
To: <curl-library_at_lists.sourceforge.net>
Sent: Wednesday, January 29, 2003 12:56 AM
Subject: Re: Windows people -- help needed!

I'm sorry if my Windows multithreading experience isn't up to snuff, but if
you use CreateThread and WaitForSingleObject with a timeout, and the timeout
occurs, what can you do about it? I don't believe there's a reliable way to
terminate a thread (the docs say "The TerminateThread and TerminateProcess
functions should be used only in extreme circumstances, since they do not
allow threads to clean up, do not notify attached DLLs, and do not free the
initial stack."); and if you're suggesting that it's the thread calling
gethostbyname() that calls WaitForSingleObject, then if the call to
gethostbyname() blocks, you never get to WaitForSingleObject...

----- Original Message -----
From: "Chris Russell" <cdr_at_encapsule.com>
To: <curl-library_at_lists.sourceforge.net>
Sent: Tuesday, January 28, 2003 1:43 PM
Subject: Re: Windows people -- help needed!

Using WSAAyncGetHostByName is *way* overkill. Creating Windows message pump
to catch messages is really not required as we can do this entirely with
CreateThread and WaitForSingleObject - no message pumps, no hidden
windows....

----- Original Message -----
From: <RBramante_at_on.com>
To: <curl-library_at_lists.sourceforge.net>
Sent: Tuesday, January 28, 2003 12:55 PM
Subject: Re: Windows people -- help needed!

If you give me a pointer on what is needed I will try to take a look at #1.

As far as #2, I can test this function out for you. One note: there is
already a non-blocking call on windows to perform hostname resolution
(WSAAsyncGetHostByName) I think this is how most Win32 applications would
probably try to do something like this rather than using another thread
(i.e. issue request, set timer, wait for either resolve or timeout). I
think it depends on how far down the road you want to start putting Win32
specific code into curl. You obviously will be using Win32 specific calls
in either case, but the async calls require the creation of a hidden window
to deliver messages to, etc,. so maybe that is a more "intrusive" solution
than the one presented....

                      Daniel Stenberg
                      <daniel_at_haxx.se> To: libcurl
Mailing list <curl-library_at_lists.sourceforge.net>
                      Sent by: cc:
                      curl-library-admin_at_lists.sour Subject: Windows
people -- help needed!
                      ceforge.net

                      01/28/2003 11:22 AM
                      Please respond to
                      curl-library

1)

Bug report #607604 was fixed a long time ago for non-windows platforms, and
I
just want to ask if there's anyone out there who could possibly consider
helping us closing the report by fixing this in the windows version as
well?

http://sourceforge.net/tracker/index.php?func=detail&aid=607604&group_id=976
&atid=100976

2)

There is also this interesting patch in bug report #674095 submitted by
aschiffler, that offers a gethostbyname() that can be aborted with a
timeout
(for Windows). I would like someone to test it/comment it to become subject
for inclusion in an upcoming libcurl version:

http://sourceforge.net/tracker/index.php?func=detail&aid=674095&group_id=976
&atid=100976

--
 Daniel Stenberg -- curl, cURL, Curl, CURL. Groks URLs.
-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com