Newsgroups : Borland : borland.public.delphi.internet.winsock : 2006 Oct : Re: Multi-Threading
| Subject: | Re: Multi-Threading |
| Posted by: | "David Fealkoff" (fealko..@iatinc.net) |
| Date: | Mon, 16 Oct 2006 23:11:28 |
- The application only downloads an xml file intermittently. There can be
long periods of time between downloads, followed by a succession of
downloads. I'll have to assess the trade offs of creating and destroying
objects compared to having threads taking time slots and doing nothing.
- 'Start' was taken from the sample code I used as a model. It is a valid
method and as I first step I just tried to model the sample. The theory was
this: 'Start' calls the 'Run' procedure which in turns calls IdHTTP.Get.
The events associated with the download operation synchronize update
information to the main application. I rationalized that if the thread did
start running that since it was blocking that the thread would not 'Stop'
until everything was downloaded.
-In the meantime I found another sample which I'll examine tomorrow, but I
do have one question that I could use a little guidance on. All of the
examples I've seen pass a string back to the main thread. This is passing a
value. If I want to pass the stream back to main thread, which I believe
will be a pointer will that be a problem if the thread is destroyed? Or do
I somehow have recreate the stream in the main thread?
Thanks,
David
"Martin James" <nospam@dial.pipex.com> wrote in message
news:4533b56b$1@newsgroups.borland.com...
> Err... OK.
>
>
> First, how often does your app download a web page? If it performs
> downloads often, there is little point in continually
> creating/terminating/freeing threads and other complex components, (like
> TidHTTP), to do the downloads - it's much easier and safer to keep the
> threads and components around.
>
> Then there's this:
>
> Start;
> finally
> downloadThread.Free;
>
> I'm not sure what 'start' does either but, unless it is a synchronous
> signaling mechanism, (which I'm pretty sure it is not), there is a real
> chance that the download thread will not run at all because you are
> freeing it in the very next line. Even if the OS does run the download
> thread immediately, (either on another processor or by preempting the main
> thread), the first time the download thread blocks, (as it will on the
> TidHTTP socket calls), the main thread will run again and the download
> thread will be freed. What happens in TidThread.destroy I do not know,
> but I'm pretty sure that you do not want to call it before the download
> thread has actually done some downloading.
>
>
> Remy Lebeau, (Indy expert), may well find other issues/problems <g>
>
>
> Rgds,
> Martin