Asynchronous WinInet

[Steve Thresher]

Is there a difference between using the WinInet function HttpSendRequest()
asychronously and calling the function on a new thread?

I'm currently using HttpSendRequest() on a separate thread but it still
seems to be blocking the winsock 'keepalives' that are sent between our
client and server programs.

[Visu]

calls to HttpSendRequest() or CHttpFile::SendRequest() will hang
unpredictably....so, better to avoid these calls where as possible. Can
you post your code or outline of usage of these functions, so that I
can suggest you the best possible way to do it.

[Paul Baker]

There is a big difference in how you write the code. There is not a big
difference in the user's experience, if written properly. Therefore, I
always opt for the thread option. I find the code easier to write and more
reliable.

To cancel the thread, just close the handle on which the blocking thread is
based, or any of its parents.

Paul

Post by Steve Thresher
Is there a difference between using the WinInet function HttpSendRequest()
asychronously and calling the function on a new thread?
I'm currently using HttpSendRequest() on a separate thread but it still
seems to be blocking the winsock 'keepalives' that are sent between our
client and server programs.

[Steve Thresher]

The problem I have is that the request is to take payment from a credit card
so will killing the thread stop the request from going through or just stop
me from getting a response?

Post by Paul Baker
There is a big difference in how you write the code. There is not a big
difference in the user's experience, if written properly. Therefore, I
always opt for the thread option. I find the code easier to write and more
reliable.
To cancel the thread, just close the handle on which the blocking thread
is based, or any of its parents.
Paul

Post by Steve Thresher
Is there a difference between using the WinInet function
HttpSendRequest() asychronously and calling the function on a new thread?
I'm currently using HttpSendRequest() on a separate thread but it still
seems to be blocking the winsock 'keepalives' that are sent between our
client and server programs.

[Paul Baker]

I did not express myself clearly.

To cancel the thread, don't call TerminateThread ("kill" it). Instead, call
InternetCloseHandle on the HINTERNET handle being used by the function that
is blocking. In this case, the request handle. This will cause the function
to fail (the error code varies between versions of WinInet) and stop
blocking. Therefore the thread will naturally end.

Paul

Post by Steve Thresher
The problem I have is that the request is to take payment from a credit
card so will killing the thread stop the request from going through or
just stop me from getting a response?

Post by Paul Baker
There is a big difference in how you write the code. There is not a big
difference in the user's experience, if written properly. Therefore, I
always opt for the thread option. I find the code easier to write and
more reliable.
To cancel the thread, just close the handle on which the blocking thread
is based, or any of its parents.
Paul

Post by Steve Thresher
Is there a difference between using the WinInet function
HttpSendRequest() asychronously and calling the function on a new thread?
I'm currently using HttpSendRequest() on a separate thread but it still
seems to be blocking the winsock 'keepalives' that are sent between our
client and server programs.

[Scherbina Vladimir]

This post might be inappropriate. Click to display it.

[Paul Baker]

Although it is true that closing the handle will not stop the thread, it
will cause it to exit any WinInet function that uses the handle or anything
derived from it. Therefore, your thread will naturally exit ir written
correctly.

I agree that TerminateThread should not be used.

I don't agree that asynchronous operation is the best solution, as your
opinion that it is is based on faulty information regarding the behaviour of
WinInet and InternetCloseHandle.

Paul

Post by Scherbina Vladimir

Post by Paul Baker
There is a big difference in how you write the code. There is not a big
difference in the user's experience, if written properly. Therefore, I
always opt for the thread option. I find the code easier to write and
more reliable.
To cancel the thread, just close the handle on which the blocking thread
is based, or any of its parents.

Just closing handle would not stop your thread. You need to make some kind
of notifications to the thread to allow him "understand" that you want to
terminate it. Sure you may call TerminateThread but this is not
recommended way.
Async. wininet gives you more control over the data tramsmission process.
I've met situations when recieving (or sending) thread is hunging IN
wininet function, and you cannot notify thread to terminate (because
wininet code is executing at this moment) so the only way to stop
processing is terminating thread. In this way you would not make
InternetCloseHandle and another neccessary calls to cleanup resources.
When using wininet in async. way you're able to overcome all above
problems.
--
Vladimir

[Scherbina Vladimir]

This post might be inappropriate. Click to display it.

[Paul Baker]

Hmm, you make an interesting point. I have not seen a real life situation
where there is a noticable delay between a call to InternetCloseHandle and
the WinInet function exiting, but I can see how that could be possible.

What I do is call InternetCloseHandle and wait for the thread to terminate
when the associated UI is already closed so that if there is a delay, the
user does not notice it.

I guess it's a matter of preference.

Paul

Post by Scherbina Vladimir

Post by Paul Baker
Although it is true that closing the handle will not stop the thread, it
will cause it to exit any WinInet function that uses the handle or
anything derived from it.

If you're talking about *InternetCloseHandle*, then you're right, I was
referring to "CloseHandle" on a thread handle (at least that was
understandable from the contex of my message)

Post by Paul Baker
Therefore, your thread will naturally exit ir written correctly.
I agree that TerminateThread should not be used.
I don't agree that asynchronous operation is the best solution, as your
opinion that it is is based on faulty information regarding the behaviour
of WinInet and InternetCloseHandle.

It gives you more control. Real life shows that just closing handle when
thread is hunging in wininet.dll often does not change the situation.
--
Vladimir

[Paul Baker]

Sorry, I see that I was very unclear that I was talking about
InternetCloseHandle to close an HINTERNET handle (not CloseHandle to close a
thread handle).

Paul

Post by Scherbina Vladimir

Post by Paul Baker
Although it is true that closing the handle will not stop the thread, it
will cause it to exit any WinInet function that uses the handle or
anything derived from it.

If you're talking about *InternetCloseHandle*, then you're right, I was
referring to "CloseHandle" on a thread handle (at least that was
understandable from the contex of my message)

Post by Paul Baker
Therefore, your thread will naturally exit ir written correctly.
I agree that TerminateThread should not be used.
I don't agree that asynchronous operation is the best solution, as your
opinion that it is is based on faulty information regarding the behaviour
of WinInet and InternetCloseHandle.

It gives you more control. Real life shows that just closing handle when
thread is hunging in wininet.dll often does not change the situation.
--
Vladimir