TNMHTTP vs. TIdHTTP

#76

Author: Carlos Moreno
Date: Mon, 21 Apr 2008 22:35

61 lines
3074 bytes


On a subject somewhat related to my previous post... 

I guess a preliminary question would have to be whether there is 
a package library that I could install with C++ Builder 2007 that 
would give me access to the "legacy" TNMHTTP control  (how can I 
find out what packages contain what, and whether or not something 
is available?)

Anyway, the issue I have right now is the following:  I replaced 
the TNMHTTP control with an Indy control TIdHTTP, for an 
auxiliary class that I have that retrieves an image from a 
web site and places it in a TImage control (providing local 
caching of images, etc.).

The HTTP control is in a class that inherits from Thread.  In 
the Execute method of this class, I do  (exception-handling and 
other housekeeping omitted):

    http = new TIdHTTP (Application);  // http is a data member
    TFileStream * file = new .... (localfile.c_str() ... );
        // localfile is also a data member, an std::string
    http->Get (url, file);
    delete file;
    Synchronize (SetImage);


Where my SetImage method looks like this:

    image->Picture->LoadFromFile (localfile.c_str());
        // image is a data member, a TImage * that was 
        // passed to the constructor, so that this object 
        // places the image in that control

With TNMHTTP, the above was working flawlessly;  it's on a 
separate thread, so it does not block the GUI.  In particular, 
if I have multiple downloads going on concurrently, I see them 
appear one by one.

However, with the Indy HTTP control, it would seem like it does 
block everything --- I can't even grab the main window and move 
it;  everything freezes until *all* downloads are completed and 
the images do show up  (all of them simultaneously).

How could this happen?   The HTTP control is running on a 
separate thread --- how come it blocks the entire GUI? (the 
constructor sets Priority to tpLower, by the way)

I also tried passing NULL to TIdHTTP's constructor  (really 
a shot in the dark).  The behaviour remains identical --- it 
works, but it freezes the GUI until all downloads are completed 
and all the images show up.

Any explanation for this?

Thanks!

Carlos
--

Re: TNMHTTP vs. TIdHTTP

#77

Author: Dennis Cote
Date: Mon, 21 Apr 2008 23:27

13 lines
1315 bytes

Carlos Moreno wrote:
> 
> However, with the Indy HTTP control, it would seem like it does 
> block everything --- I can't even grab the main window and move 
> it;  everything freezes until *all* downloads are completed and 
> the images do show up  (all of them simultaneously).
> 
> Any explanation for this?
> 

You probably need to add a TIdAntiFreeze component to your application.

Dennis Cote

Re: TNMHTTP vs. TIdHTTP

#79

Author: Remy Lebeau (TeamB)
Date: Tue, 22 Apr 2008 00:13

34 lines
2189 bytes

"Carlos Moreno" <moreno_h3gd@mochima.com> wrote in message 
news:480d16b3$1@newsgroups.borland.com...

> With TNMHTTP, the above was working flawlessly;  it's on a
> separate thread, so it does not block the GUI.  In particular,
> if I have multiple downloads going on concurrently, I see them
> appear one by one.

That should also be the case with TIdHTTP.  I use TIdHTTP myself in separate 
threads and it works fine for me.

> However, with the Indy HTTP control, it would seem like it
> does block everything

No, it would not.

> I can't even grab the main window and move it; everything freezes
> until *all* downloads are completed and the images do show up
> (all of them simultaneously).

Then you are somehow deadlocking the code that is running in the main 
thread.  That has nothing to do with TIdHTTP itself.

> The HTTP control is running on a separate thread --- how
> come it blocks the entire GUI?

TIdHTTP does not.  None of its operations are running in the main thread, so 
there is nothing to block.  So it has to be your own code that is being 
called by Synchronize() that is doing something it should not be doing, and 
thus blocking the main thread.


Gambit

Re: TNMHTTP vs. TIdHTTP

#78

Author: Remy Lebeau (TeamB)
Date: Tue, 22 Apr 2008 00:14

12 lines
1299 bytes

"Dennis Cote" <denniscote@gmail.com> wrote in message 
news:480d22fc@newsgroups.borland.com...

> You probably need to add a TIdAntiFreeze component to your application.

That only applies to Indy components that are used in the context of the 
main thread.  Using them in the context of worker threads instead will not 
invoke TIdAntiFreeze even if it were present in the project.


Gambit

Re: TNMHTTP vs. TIdHTTP

#80

Author: Carlos Moreno
Date: Tue, 22 Apr 2008 01:45

40 lines
2284 bytes

Dennis Cote <denniscote@gmail.com> wrote:
>Carlos Moreno wrote:
>> 
>> However, with the Indy HTTP control, it would seem like it does 
>> block everything --- I can't even grab the main window and move 
>> it;  everything freezes until *all* downloads are completed and 
>> the images do show up  (all of them simultaneously).
>> 
>> Any explanation for this?
>> 
>
>You probably need to add a TIdAntiFreeze component to your application.

Ok, this is shockingly interesting...  *AntiFreeze* component!! 
Whoh!  Seems like something taken from a Sci-Fi show!  :-)

Anyway, from the description I see in the docs, I still don't 
see how it could have anything to do with it.  Sure, the call 
to TIdHTTP::Get does block, as did the call to TNMHTTP::Get, 
but that's why I place the component in a separate thread, with 
low priority.

In the TIdAntiFreeze documentation, they say that if some of 
these blocking calls occur in the main Thread, then the GUI 
could block/freeze, and that the AntiFreeze component is useful 
to counter this effect. 

But that's the thing --- it's not in the main thread in my 
case.  Unless the HTTP control does make use of some global 
resource that in turn blocks the main thread?   (that would 
be a *major* worry, as that would seem to suggest that the 
component is inherently non-thread-safe?   Sounds strange, 
though...)

Thanks,

Carlos
--

Re: TNMHTTP vs. TIdHTTP

#81

Author: Carlos Moreno
Date: Tue, 22 Apr 2008 02:31

33 lines
2257 bytes


>> The HTTP control is running on a separate thread --- how
>> come it blocks the entire GUI?
>
>TIdHTTP does not.  None of its operations are running in the main thread, so 
>there is nothing to block.  So it has to be your own code that is being 
>called by Synchronize() that is doing something it should not be doing, and 
>thus blocking the main thread.

This sounds reasonable, of course.  The puzzling aspect is that 
it did not behave this way when using TNMHTTP;  the very only 
thing I changed was this (TNMHTTP replaced by TIdHTTP); nothing 
else in the application changed.  (well, several lines changed 
in the code that downloads the content, since the syntax and 
interface for TIdHTTP changes with respect to TNMHTTP --- but 
the changes are absolutely confined to this one file;  nothing 
changed in the rest of the application)

I just tried to see if it could be the file (TFileStream) passed 
to TIdHTTP::Get to indicate where to put the downloaded content 
(which is the one prominent difference w.r.t. TNMHTTP);  I 
added a random component to the file name, in case it could 
be that the same file was downloaded from multiple places 
concurrently.   Did not change the behaviour.

Anyway, will continue to think about this, and look for possible 
suspects!

Thanks,

Carlos
--

Re: TNMHTTP vs. TIdHTTP

#82

Author: Remy Lebeau (TeamB)
Date: Tue, 22 Apr 2008 03:23

21 lines
1553 bytes

"Carlos Moreno" <moreno_h3gd@mochima.com> wrote in message 
news:480d4345$1@newsgroups.borland.com...

> In the TIdAntiFreeze documentation, they say that if some of
> these blocking calls occur in the main Thread, then the GUI
> could block/freeze, and that the AntiFreeze component is useful
> to counter this effect.
>
> But that's the thing --- it's not in the main thread in my
> case.

Which is exactly why TIdAntiFreeze will have no effect in your code.

> Unless the HTTP control does make use of some global resource
> that in turn blocks the main thread?

No, it does not.


Gambit

Re: TNMHTTP vs. TIdHTTP

#83

Author: Dennis Cote
Date: Tue, 22 Apr 2008 15:59

35 lines
2721 bytes

Carlos Moreno wrote:
> 
> This sounds reasonable, of course.  The puzzling aspect is that 
> it did not behave this way when using TNMHTTP;  the very only 
> thing I changed was this (TNMHTTP replaced by TIdHTTP); nothing 
> else in the application changed.  (well, several lines changed 
> in the code that downloads the content, since the syntax and 
> interface for TIdHTTP changes with respect to TNMHTTP --- but 
> the changes are absolutely confined to this one file;  nothing 
> changed in the rest of the application)
> 

Which version of Indy are you using?

I had a similar problem with a combination of TIdICMPClient and 
TIdTelnetClient clients that would take long to very long pauses. While 
paused my application was locked as you describe. I couldn't move a 
window, and it didn't respond to mouse or keyboard input. After a pause 
the application would process all the queued input and continue normally 
and until the next pause. The length of the pause varied from several 
seconds to infinite (i.e. longer than I cared to wait, more than a few 
hours).

This issue first appeared with the version of Indy 9 shipped with BDS 
2006. I had no such problems using Indy 8 and older versions of Indy 9 
with BCB 6. The problems continued when I switched to the (very old) 
version of Indy 10 supplied with RAD 2007.

This problems disappeared when I switched from the old Indy 10 version 
supplied with RAD Studio 2007 to the current development snapshot 
version (about 2 weeks ago). I don't believe there were any substantive 
changes to my application that would have caused this change in 
behavior. I assume there was a bug in Indy that has been fixed.

Dennis Cote

Re: TNMHTTP vs. TIdHTTP

#84

Author: Carlos Moreno
Date: Tue, 22 Apr 2008 17:12

20 lines
1516 bytes


>Which version of Indy are you using?

The test was done with Borland C++ Builder 6, Update 4  (the 
latest from version 6, AFAIK).

I just purchased C++ Builder 2007 R2, but I have not yet 
installed it --- I had been playing with the trial edition 
that I had.

I'll run some tests with C++B2007 R2 once I install it to 
see if the behaviour is the same as what I'm seeing when I 
change the TNMHTTP to TIdHTTP in our application that we're 
trying to migrate from BC++B6 to BC++B2007. 

Thanks!

Carlos
--

🚀 go-pugleaf

Thread View: borland.public.cppbuilder.internet.socket

TNMHTTP vs. TIdHTTP

Re: TNMHTTP vs. TIdHTTP

Re: TNMHTTP vs. TIdHTTP

Re: TNMHTTP vs. TIdHTTP

Re: TNMHTTP vs. TIdHTTP

Re: TNMHTTP vs. TIdHTTP

Re: TNMHTTP vs. TIdHTTP

Re: TNMHTTP vs. TIdHTTP

Re: TNMHTTP vs. TIdHTTP

Thread Navigation