cURL / Mailing Lists / curl-library / Single Mail

curl-library

Re: Windows people -- help needed!

From: Chris Russell <cdr_at_encapsule.com>
Date: Tue, 28 Jan 2003 13:41:28 -0500

Daniel, I don't think you completely understood my post (I didn't explain
too well - sorry).

I should have quoted the excerpt from the Microsoft API documentation so as
not to confuse everyone.

I only suggest that that win32 gethostbyname API call be used as a
quick-n-dirty GO/NO-GO test to see if the network connection is okay. How it
actually does what it does on Windows is not important. The data it returns
is not important. All we care is if it returns within a prescribed period of
time. If it does not, then we say THE CONNECTION IS DEAD. Otherwise, we
assume that it's okay and proceed. So I'm not advocating some alternate
implementation for existing curl functionality at all - just a sleazy little
test involving an win32 API call.

The business of spawning a worker thread to make the call and then blocking
on the thread handle allows us to implement a light-weight timeout mechanism
for an win32 API function that does not support a timeout natively. But we
don't need to transfer data between the worker and the mater thread because
all we care about is the return value of WaitForSingleObject - is it a
timeout or not? You follow?

----- Original Message -----
From: "Daniel Stenberg" <daniel_at_haxx.se>
To: "libcurl Mailing list" <curl-library_at_lists.sourceforge.net>
Sent: Tuesday, January 28, 2003 12:45 PM
Subject: Re: Windows people -- help needed!

On Tue, 28 Jan 2003, Chris Russell wrote:

Thanks a lot for your knowledgeable input!

> The gethostbyname function returns a pointer to a HOSTENT structure-a
> structure allocated by Windows Sockets. The HOSTENT structure contains the
> results of a successful search for the host specified in the name
> parameter.

We already have the functionality in libcurl that clones a hostent
structure,
and it is proven to work. (We use this to allow windows-application that use
libcurl to pass libcurl easy-handles between threads.)

> the win32 api call gethostbyname could potentially be used to check the
> health of the network connection prior to opening a socket.

I don't see the purpose for the timeout quite like that. I see the main
purpose of a gethostbyname-timeout to offer the application the ability to
control how much time to spend. Other platforms already support this thanks
to the use of signals.

> The gethostbyname function cannot resolve IP address strings passed to it.

We never do that in libcurl, we detect and handle IP addresses differently.

> My suggestion would be to internally spawn a worker thread to make the
> gethostbyname call. All the worker thread does is make the gethostbyname
> call - we don't even really care about the result. The main thread then
> blocks using WaitForSingleObject passing in the thread handle as the
> synchronization object and a non-infinite timeout. Should the main thread
> fall out of wait due to a timeout we know the interface is hosed. So as
not
> to screw anything up, should the timeout occur, we just leave the worker
> out hanging in the ether until the process is terminated (thus cleaning up
> any structures allocated by windows sockets), and killing the worker.

But in case of a successful lookup, it would need to pass the data between
the threads somehow, possibly by using the current struct-clone function?

Also, leaving the worker thread hanging like seems like a bad idea if we
repeatedly invoke fetches that are aborted without the application ever
terminating, as then we'll get more and more zombies lying around...

--
 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
Received on 2003-01-28