Asynch wininet - Threaded or not?

Hi,

If I use asynch Wininet is there any purpose in hiving of the Wininet calls
into separate threads and the extra complication which ensues? As from what
I can see the system starts a separate thread implicitly for the asynch
calls anyway.
The reason I ask is I imagine the thread switching might ensure that the UI
remains responsive - plus there may be other issues you can enlighten me
with.

My application is "real-time" and will be applied to a Pocket PC/Smartphone
as well as WinXP so I need the quickest/most efficient functionality
possible.

Also the UI response must be as fast as possible.

The application basically "GET"s a website for info then issues occasional -
through crucial "POST"s prompted by the user via the UI.

Both the GETS and POSTS must be carried out as close to real-time as
possible.

TIA

Scherbina
Wed Feb 01 15:27:06 CST 2006

Hello, Fred.

"Fred" <not@home.com> wrote in message
news:C_idneF4PNibVn3eRVnyrg@pipex.net...
> Hi,
>
> If I use asynch Wininet is there any purpose in hiving of the Wininet
> calls
> into separate threads and the extra complication which ensues? As from
> what
> I can see the system starts a separate thread implicitly for the asynch
> calls anyway.
> The reason I ask is I imagine the thread switching might ensure that the
> UI
> remains responsive - plus there may be other issues you can enlighten me
> with.
>
> My application is "real-time" and will be applied to a Pocket
> PC/Smartphone
> as well as WinXP so I need the quickest/most efficient functionality
> possible.
>
> Also the UI response must be as fast as possible.
>
> The application basically "GET"s a website for info then issues
> occasional -
> through crucial "POST"s prompted by the user via the UI.
>
> Both the GETS and POSTS must be carried out as close to real-time as
> possible.
> TIA

Even if you use wininet synchronously system might create additional threads
and you cannot control this behavour. So putting async. calls into separate
thread is useless.

You may achieve the fastest result by creating the "worker" thread that
waits on some object (for instance, event) and when GUI thread is going to
make a GET or POST it sets the event and allows worker thread to accomplish
the actual work using syncronous wininet calls.

--
Vladimir

Fred
Wed Feb 01 18:58:05 CST 2006


"Scherbina Vladimir" <vladimir.scherbina@gmail.com> wrote in message
news:OWC$HY3JGHA.1088@tk2msftngp13.phx.gbl...
> Hello, Fred.
>

> Even if you use wininet synchronously system might create additional
threads
> and you cannot control this behavour. So putting async. calls into
separate
> thread is useless.
>
> You may achieve the fastest result by creating the "worker" thread that
> waits on some object (for instance, event) and when GUI thread is going to
> make a GET or POST it sets the event and allows worker thread to
accomplish
> the actual work using syncronous wininet calls.
>
> --
> Vladimir

Hi,

I have built a related application which uses synchronous Wininet. However I
have never worked out how to terminate a single thread if it hangs. The MS
workarounds to the wininet bug seem to terminate all active Wininet calls.

Fred
Wed Feb 01 19:31:17 CST 2006


"Paul Baker" <paulb@online.rochester.rr.com> wrote in message
news:OamuOD1JGHA.420@tk2msftngp13.phx.gbl...
> My preference is to use WinInet synchronously in a multi-threaded
> environment.
>

Hi,

Is it just a preference or have you experienced better performance?

See also my post about hanging threads. They cannot easily be handled in a
synchronous environment (AFAIK ).
As INTERNET_OPTION_CONNECT_TIMEOUT doesn't work.

Scherbina
Wed Feb 01 23:33:50 CST 2006

> Hi,
>
> I have built a related application which uses synchronous Wininet. However
> I
> have never worked out how to terminate a single thread if it hangs. The MS
> workarounds to the wininet bug seem to terminate all active Wininet calls.

Documentation states that if you have a thread that is reading or writing
something to/from stream using HINTERNET handle you can close that handle on
another thread using InternetCloseHandle. So if you have you "worker"
sending POST or GET via HttpSendRequest closing HINTERNET handle that is
used in HttpSendRequest will cancel sending request.

--
Vladimir

Fred
Thu Feb 02 05:31:47 CST 2006


"Scherbina Vladimir" <vladimir.scherbina@gmail.com> wrote in message
news:u871So7JGHA.3504@TK2MSFTNGP10.phx.gbl...
> > Hi,
> >
> > I have built a related application which uses synchronous Wininet.
However
> > I
> > have never worked out how to terminate a single thread if it hangs. The
MS
> > workarounds to the wininet bug seem to terminate all active Wininet
calls.
>
> Documentation states that if you have a thread that is reading or writing
> something to/from stream using HINTERNET handle you can close that handle
on
> another thread using InternetCloseHandle. So if you have you "worker"
> sending POST or GET via HttpSendRequest closing HINTERNET handle that is
> used in HttpSendRequest will cancel sending request.

I have read that the cancelling thread MS fix,
http://support.microsoft.com/kb/224318/EN-US/ will cancell all threads
currently accessing the Internet - although I can't find the original
reference which details this.

I have also come across this assertion:

"The async mode is most suited to applications which must be single threaded
and stay responsive to the end user and in extreme performance and memory
sensitive situations"

Although that was in a very old book :)

Fred
Thu Feb 02 13:38:49 CST 2006


"Paul Baker" <paulb@online.rochester.rr.com> wrote in message
news:%237j2CGAKGHA.2064@TK2MSFTNGP11.phx.gbl...
> Fred,
>
> As far as I know, INTERNET_OPTION_CONNECT_TIMEOUT does work. Rather than
> base the entire design of your software on the premise that it does not, I
> would go into more detail about that here and someone should be able to
help
> you. You might also closely review the documentation regarding the use of
> this constant.
>
> It does not affect performance. It's simply easier to use WinInet
> synchronously rather than asynchronously. And creating a thread is almost
> trivial.
>
> To terminate a synchronous operation, all you need to do is close the
handle
> on which it acts or one if its parents.
>

Could you be explicit with a code snippet as I remain confused given the MS
support docs

http://support.microsoft.com/kb/176420/EN-US/
http://support.microsoft.com/kb/224318/EN-US/

Say I have several threads carrying out their own requests. One of them is
taking too long.
and I wish to terminate that request yet leave the others untouched.

How do i do it?

Thanks

Fred
Thu Feb 02 13:40:45 CST 2006


"Paul Baker" <paulb@online.rochester.rr.com> wrote in message
news:%23mnYATAKGHA.3696@TK2MSFTNGP15.phx.gbl...
> Fred,
>
> Let's discuss what your old book says:
>
> "The async mode is most suited to applications which must be single
threaded
> and stay responsive to the end user and in extreme performance and memory
> sensitive situations"
>
> This is technically true, but don't be misled by it!
>
> If an application must be single threaded, then synchronous mode by
> definition will prevent it from returning to the message loop until it is
> done. However, there is no such application in practice. Who's stopping
you
> from using multiple threads? Nobody! Only your own lack of knowledge about
> multithreaded programming, perhaps.

Yes as far as synchronous/asynchronous Wininet and multithreading is
concerned.
I have written a pretty complicated prog with a thread pool and synchronous
Wininet and it works - but I'm still not happy about cancelling threads when
we have a timed-out block.

> The rest of it is presumably talking about the expense of creating a
thread.
> It takes a little time and it allocates some memory (the largest part of
> which is the stack). However, these are not really relevant issues for
most
> applications. You're not going to be downloading thousands of web pages at
> once are you?

What is the extra complexity involved in writing asynch wininet?

MS's asyncdemo doesn't look too bad

http://msdn.microsoft.com/library/en-us/wininet/wininet/calling_wininet_functions_asynchronously.asp

Fred
Thu Feb 02 13:48:25 CST 2006


"Fred" <not@home.com> wrote in message
news:b-ydnYTQkZ2g_X_eRVnysw@pipex.net...
>
> "Paul Baker" <paulb@online.rochester.rr.com> wrote in message
> news:%23mnYATAKGHA.3696@TK2MSFTNGP15.phx.gbl...
> > Fred,
> >
> > Let's discuss what your old book says:
> >
> > "The async mode is most suited to applications which must be single
> threaded
> > and stay responsive to the end user and in extreme performance and
memory
> > sensitive situations"
> >
> > This is technically true, but don't be misled by it!
> >
> > If an application must be single threaded, then synchronous mode by
> > definition will prevent it from returning to the message loop until it
is
> > done. However, there is no such application in practice. Who's stopping
> you
> > from using multiple threads? Nobody! Only your own lack of knowledge
about
> > multithreaded programming, perhaps.
>
> Yes as far as synchronous/asynchronous Wininet and multithreading is
> concerned.
> I have written a pretty complicated prog with a thread pool and
synchronous
> Wininet and it works - but I'm still not happy about cancelling threads
when
> we have a timed-out block.
>
> > The rest of it is presumably talking about the expense of creating a
> thread.
> > It takes a little time and it allocates some memory (the largest part of
> > which is the stack). However, these are not really relevant issues for
> most
> > applications. You're not going to be downloading thousands of web pages
at
> > once are you?
>
> What is the extra complexity involved in writing asynch wininet?
>
> MS's asyncdemo doesn't look too bad
>
>
http://msdn.microsoft.com/library/en-us/wininet/wininet/calling_wininet_functions_asynchronously.asp
>

Incidentally it also uses threads!!!!!!

Scherbina
Thu Feb 02 14:24:13 CST 2006

Associate handle of thread with a list of HINTERNET handles that are using
in thread. When you see that thread is working "too long", call
InternetCloseHandle on those HINTERNET handles. This is the simplest
solution.

--
Vladimir

"Fred" <not@home.com> wrote in message
news:C8OdncN-o9BUwn_eRVny2w@pipex.net...
>
> "Paul Baker" <paulb@online.rochester.rr.com> wrote in message
> news:%237j2CGAKGHA.2064@TK2MSFTNGP11.phx.gbl...
>> Fred,
>>
>> As far as I know, INTERNET_OPTION_CONNECT_TIMEOUT does work. Rather than
>> base the entire design of your software on the premise that it does not,
>> I
>> would go into more detail about that here and someone should be able to
> help
>> you. You might also closely review the documentation regarding the use of
>> this constant.
>>
>> It does not affect performance. It's simply easier to use WinInet
>> synchronously rather than asynchronously. And creating a thread is almost
>> trivial.
>>
>> To terminate a synchronous operation, all you need to do is close the
> handle
>> on which it acts or one if its parents.
>>
>
> Could you be explicit with a code snippet as I remain confused given the
> MS
> support docs
>
> http://support.microsoft.com/kb/176420/EN-US/
> http://support.microsoft.com/kb/224318/EN-US/
>
> Say I have several threads carrying out their own requests. One of them is
> taking too long.
> and I wish to terminate that request yet leave the others untouched.
>
> How do i do it?
>
> Thanks
>
>
>
>

Fred
Fri Feb 03 06:05:22 CST 2006


"Scherbina Vladimir" <vladimir.scherbina@gmail.com> wrote in message
news:e4CIxZDKGHA.1132@TK2MSFTNGP10.phx.gbl...
> Associate handle of thread with a list of HINTERNET handles that are using
> in thread. When you see that thread is working "too long", call
> InternetCloseHandle on those HINTERNET handles. This is the simplest
> solution.

Hi,

The demo http://support.microsoft.com/kb/224318/EN-US/

uses the handle for InternetOpen () to close the thread if the thread is
hanging. So if I have multiple connections (threads) from the one
InternetOpen () (which is the recommended technique) then any wininet
activity must surely be terminated on *all* these threads - which is not
what I want.

Now documentation states:

"The application can make any number of calls to InternetOpen, though a
single call is normally sufficient. "

So to stop one hanging thread then I would have to have a separate
InternetOpen for each thread and then a separate Internetconnect() too -
what is the overhead for this? Surely it is more than marginal - and don't
forget I will be porting to SmartPhone which has nowhere near the horsepower
of a PC.

These above concerns are the issues which prompted my initial post.

So, how do you handle hanging/blocking threads? Terminating them all when
only one is blocking, say on an InternetReadFile() cannot be the ideal
solution.

Further can you actual terminate on any blocking wininet function, say if
InternetReadFile() is blocking or does it only work for Internetconnect?

Thanks

Scherbina
Fri Feb 03 06:59:31 CST 2006

Hello, Fred.

"Fred" <not@home.com> wrote in message
news:Htmdnc13puaf2n7eRVnygQ@pipex.net...
>
> The demo http://support.microsoft.com/kb/224318/EN-US/
>
> uses the handle for InternetOpen () to close the thread if the thread is
> hanging. So if I have multiple connections (threads) from the one
> InternetOpen () (which is the recommended technique) then any wininet
> activity must surely be terminated on *all* these threads - which is not
> what I want.
>
> Now documentation states:
>
> "The application can make any number of calls to InternetOpen, though a
> single call is normally sufficient. "
>
> So to stop one hanging thread then I would have to have a separate
> InternetOpen for each thread and then a separate Internetconnect() too -
> what is the overhead for this? Surely it is more than marginal - and don't
> forget I will be porting to SmartPhone which has nowhere near the
> horsepower
> of a PC.
>
> These above concerns are the issues which prompted my initial post.
>
> So, how do you handle hanging/blocking threads? Terminating them all when
> only one is blocking, say on an InternetReadFile() cannot be the ideal
> solution.
>
> Further can you actual terminate on any blocking wininet function, say if
> InternetReadFile() is blocking or does it only work for Internetconnect?
>
> Thanks

There is no need to make an InternetOpen in all threads - this is a really
overhead. You may call InternetOpen once and use returned handle in all
threads.

Each thread (or thread from the pool) makes InternetConnect using handle
returned by InternetOpen. Most likely your thread would not be blocked by
call of InternetConnect, it might hung when you will make call to
HttpOpenRequest / HttpSendRequst, so to cancel blocking of thread you should
close handle of request(or whatever) it made. Microsofts examples closes
handle returned by InternetOpen, but you may cancel execution closing handle
returned by HttpOpenRequest or simular function.

So, once more:

1. Locate where your thread may hung (InternetReadFile, HttpSendRequest,
etc)
2. Associate HINTERNET handles open by thread with thread's handle.
3. Mark position *what* wininet function is executed in each thread.
4. When thread is hung, read the position - you know what function is
executed, and the handle it uses, simply close it.

--
Vladimir

Fred
Fri Feb 03 12:36:18 CST 2006


"Scherbina Vladimir" <vladimir.scherbina@gmail.com> wrote in message
news:uUrkuGMKGHA.2392@TK2MSFTNGP09.phx.gbl...
> Hello, Fred.
>

> Each thread (or thread from the pool) makes InternetConnect using handle
> returned by InternetOpen. Most likely your thread would not be blocked by
> call of InternetConnect, it might hung when you will make call to
> HttpOpenRequest / HttpSendRequst, so to cancel blocking of thread you
should
> close handle of request(or whatever) it made. Microsofts examples closes
> handle returned by InternetOpen, but you may cancel execution closing
handle
> returned by HttpOpenRequest or simular function.
>
> So, once more:
>
> 1. Locate where your thread may hung (InternetReadFile, HttpSendRequest,
> etc)
> 2. Associate HINTERNET handles open by thread with thread's handle.
> 3. Mark position *what* wininet function is executed in each thread.
> 4. When thread is hung, read the position - you know what function is
> executed, and the handle it uses, simply close it.


OK,

I'll try it.

Cheers