David Fealkoff wrote:
> - 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.
NO!! Threads that are not running, eg. are waiting on a
Producer-Consumer Queue, (eg. a Windows message queue), for download
work requests, are not given any processor time at all by the OS. No
CPU is wasted doing nothing. Threads that are not in the running state
are just dead code, nothing is executing and 100% of your CPU is
available for the main thread and/or other apps.
> - '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.
This is possible, maybee probable, but I would not like to do such a
provocative action <g>
> -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?
>
Oooh no! I hate copying bulk data!
Post off the whole stream instance and destroy it later in the main
thread. If using threads that stay around and loop around a queue for
work, you can store everything in one 'transaction object' that contains
both the request and results, (or error/exception message), eg, simply:
-----------------------------
TdownloadTransaction=class
FURI:string;
resultStream:TmemoryStream;
errorMess:string;
constructor create(URI:string);
destructor destroy; override;
end;
..
constructor TdownloadTransaction.create(URI:string);
begin
inherited create;
FURI:=URI;
resultStream:=TmemoryStream.create;
end;
..
destructor TdownloadTransaction.destroy;
begin
resultStream.free;
inherited destroy;
end;
-----------------------------
Create one of these, queue it to the downloadthread or pass it in the
thread constructor. The TidHTTP in the thread does the work and you can
then signal the TDT back to the main thread again, eg. with a
synchronized method or PostMessage.
Rgds,
Martin
