1

Topic: 2 cycles in a flow devour storage

Kind time of days;
There is a flow which everyone 10 , reads a broad gull.
In it there are 2 cycles which analyze the last line of a broad gull, and select from it values of the parameters necessary to me (for their display in the program). And as showed experiments, these cycles for some reason devour storage (if them  that about storage is not devoured)

procedure TFileReadThread. UpdTemp1;
begin
FMain.edTemp1.Clear;
FMain.edTemp1.Text: = Pr_ValTemp;
end;
procedure TFileReadThread. CLEAR_VALUE_VIDEO;
begin
Pr_ValGPU: = ";
Pr_ValTemp: = ";
Synchronize (UpdGPU0);
Synchronize (UpdTemp0);
Synchronize (UpdGPU1);
Synchronize (UpdTemp1);
end;
procedure TFileReadThread. Execute;
var
LFile: TStringList;
w, LIndex, LIndex1, LNumGPU, L_Length: integer;
q, LValue, LStringParams: string;
LValueTrue: boolean;
begin
while not Terminated do
begin
try
CLEAR_VALUE_VIDEO;
Pr_Status: = ' File begin reading ';
Pr_Status_Color: = clGreen;
Synchronize (UpdStatus);
LFile: = TStringList. Create;
LFile. LoadFromFile (PathFile);
//q: = LFile. Strings [1];
//w: = LFile. Count;
L_Length: = LFile. Count-1;
LStringParams: = ";
LValueTrue: = false;
LValue: = ";
LNumGPU: = 0;
for LIndex: = L_Length downto 0 do
if Pos (' GPU0 ', LFile. Strings [LIndex]) <> 0 then
begin
LStringParams: = LFile. Strings [LIndex];
for LIndex1: = 0 to length (LStringParams) do
begin
if (LStringParams [LIndex1] in [' 0 '. ' 9 ']) then
LValue: = LValue+LStringParams [LIndex1]
else
if ((LStringParams [LIndex1] = '. ')
or (LStringParams [LIndex1] = ', '))
and (LValue <> ") then
begin
LValue: = LValue + '. ';
LValueTrue: = true;
end
else
begin
if (LStringParams [LIndex1] = ' ')
and (LValueTrue) then
begin
if (FMain.edGPU0.Text = ")
and (LNumGPU = 0) then
begin
Pr_ValGPU: = LValue;
Synchronize (UpdGPU0);
end;
if (FMain.edGPU1.Text = ")
and (LNumGPU = 1) then
begin
Pr_ValGPU: = LValue;
Synchronize (UpdGPU1);
end;
inc (LNumGPU);
end
else LValueTrue: = false;
LValue: = ";
end;
end;
break;
end;
LValue: = ";
LNumGPU: = 0;
for LIndex: = L_Length downto 0 do
if Pos (' GPU0 t = ', LFile. Strings [LIndex]) <> 0 then
begin
LStringParams: = LFile. Strings [LIndex];
for LIndex1: = 0 to length (LStringParams) do
begin
if (LStringParams [LIndex1] in [' 0 '. ' 9 ']) then
LValue: = LValue+LStringParams [LIndex1]
else
begin
if (LStringParams [LIndex1] = ' A C ') then
begin
if (FMain.edTemp0.Text = ")
and (LNumGPU = 0) then
begin
Pr_ValTemp: = LValue;
Synchronize (UpdTemp0);
end;
if (FMain.edTemp1.Text = ")
and (LNumGPU = 1) then
begin
Pr_ValTemp: = LValue;
Synchronize (UpdTemp1);
end;
inc (LNumGPU);
end
else LValueTrue: = false;
LValue: = ";
end;
end;
break;
end;
Pr_Status: = ' File end reading ';
Pr_Status_Color: = clGreen;
Pr_Sleep: = IntToStr (ASleep);
//ASleep: = ASleep*1000;
Synchronize (UpdStatus);
FreeAndNil (LFile);
except
on E: Exception do
begin
Pr_Status: = ' Not access to file ';
Pr_Status_Color: = clRed;
Synchronize (UpdStatus);
FreeAndNil (LFile);
end
end;
end;
end;

That in these cycles can not give storage... I guess
In advance thanks for the answer

2

Re: 2 cycles in a flow devour storage

Sergey-2008 wrote:

that in these cycles can not give storage... I guess

FastMM + FullDebugMode help to find the answer to this question.

3

Re: 2 cycles in a flow devour storage

Moreover if a flow   that with storage will be all norms., i.e. the program will not litter it

4

Re: 2 cycles in a flow devour storage

;

type
TFileReadThread = class (TThread)
private
{Private declarations}
protected
Pr_Sleep, Pr_ValTemp0, Pr_ValTemp1, Pr_ValGPU0, Pr_ValGPU1, PathFile, Pr_Status: string;
Pr_Status_Color: TColor;
ASleep: integer;
procedure Execute; override;
procedure CLEAR_VALUE_VIDEO;
procedure EDIT_VALUE_VIDEO;
procedure UpdErrStatus;
public
constructor Create (APathFile: String;
A_Sleep: integer);
end;

5

Re: 2 cycles in a flow devour storage

But in "Pr_ValTemp", "Pr_ValGPU" digits are stored only
Each time at  a flow, storage increases on 100. (I store all in variables of 4 numbers)

6

Re: 2 cycles in a flow devour storage

Sergey-2008 wrote:

there is a flow which everyone 10 , reads a broad gull.

And where in the resulted code a section which confirms the given announcement?
I to that a cycle without

while True do
begin
==>//sleep (1000);
end;

Rather sensitively strains the CPU even at the only thing launched .. If them to launch a little there it will be even more interesting

7

Re: 2 cycles in a flow devour storage

;
The HARDWARE, seemingly, only started to study flows. Messages in the main flow did not reach yet. You see, how Synchronize intensively uses. Attempt to use a component wadman' will be a following stage smile

8

Re: 2 cycles in a flow devour storage

And here explicitly not from zero it is necessary to sort out an index

for LIndex1: = 0 to length (LStringParams) do
begin
if (LStringParams [LIndex1] in [' 0 '. ' 9 ']) then

9

Re: 2 cycles in a flow devour storage

Sergey-2008 wrote:

while not Terminated do

Terminate it is not revealed

Sergey-2008 wrote:

there is a flow which everyone 10 , reads a broad gull.

Any suspension of a flow too it is not revealed.
Whether you create each 10 seconds a new flow?

10

Re: 2 cycles in a flow devour storage

Sergey-2008;
1. Delete the created objects always strictly in try-finally;
2. Completely refuse from synchronize.
Then it will be possible to speak further.

11

Re: 2 cycles in a flow devour storage

YuRock wrote:

2. Completely refuse from synchronize.

By the way, and than you so  do not love? They like, in the last versions, altered them?

12

Re: 2 cycles in a flow devour storage

alekcvp wrote:

it is passed...
By the way, and than you so  do not love? They like, in the last versions, altered them?

But  remained ()
P.S. I use  remorselessly if I see in it necessity.

13

Re: 2 cycles in a flow devour storage

alekcvp wrote:

and than you so  do not love?

Its limitation on start by a method without parameters and absence of possibility to return
Result personally me strain. Global variables (even is local-global fields
Class) - angrily.

14

Re: 2 cycles in a flow devour storage

Dimitry Sibiryakov wrote:

it is passed...
Its limitation on start by a method without parameters and absence of possibility to return
Result personally me strain. Global variables (even is local-global fields
Class) - angrily.

Global variables, "start by a method without parameters"and"absence of possibility to return
The result "added again in one heap? smile))

15

Re: 2 cycles in a flow devour storage

Well look: when I use SendMessage I can directly transfer it two parameters and directly
To return number. Synchronize so cannot, it is necessary to use methods with the side
Effects and to transfer values through class fields.
When I use PostMessage operation proceeds without waiting, that Synchronize again
Cannot.

16

Re: 2 cycles in a flow devour storage

Dimitry Sibiryakov;
So you do not transfer, who hinders in the stack to select?

17

Re: 2 cycles in a flow devour storage

Dimitry Sibiryakov wrote:

Well look: when I use SendMessage I can directly transfer it two parameters and directly
To return number. Synchronize so cannot, it is necessary to use methods with the side
Effects and to transfer values through class fields.
When I use PostMessage operation proceeds without waiting, that Synchronize again
Cannot.

Well there are different necessities of synchronization
For example, in video observation system it is necessary  cameras on their presence.
Miss of a video stream from the camera does not say that cameras are not present in a network
Can be, it is necessary simply  a flow.
a thing long to fence around it SendMessage-PostMessage there is no sense
If time in five seconds happens Synchronize from  a flow,
There is nothing terrible.
I simply the example resulted it, if that

18

Re: 2 cycles in a flow devour storage

defecator wrote:

I simply the example resulted It, if that

It is amusing that you resulted just an example, where Synchronize, any other synchronization
Are not required at all.

19

Re: 2 cycles in a flow devour storage

Dimitry Sibiryakov wrote:

it is passed...
It is amusing that you resulted just an example, where Synchronize, any other synchronization
Are not required at all.

From your point of view - it is not required
From my point of view - it is required.

20

Re: 2 cycles in a flow devour storage

defecator wrote:

if time in five seconds happens Synchronize from  a flow,
There is nothing terrible

And than this  the flow will be better than the timer in a principal flow? A title only the beautiful.

21

Re: 2 cycles in a flow devour storage

YuRock wrote:

it is passed...
And than this  the flow will be better than the timer in a principal flow? A title only the beautiful.

For 5 seconds there will be a ten attempts  in a flow;
And the result gets out outside only time in five seconds.
What for to a principal flow generally the nobility what there something such permanently works?

22

Re: 2 cycles in a flow devour storage

alekcvp wrote:

it is passed...
By the way, and than you so  do not love? They like, in the last versions, altered them?

I do not know that there now, but that to D7, it was impossible to use on the big row of the reasons. Fortunately, in it also there is no necessity.
The standard dial-up of a rake synchronize can be seen and most, looking at implementation, well for example:
1. The call synchronize hangs for ever up, if it to cause to Application. Run;
2. Hangs for ever up, if at all call Application was not planned. Run (dll, the console...);
3. Hangs for ever up, if one more operation cycle of messages launched at handling of the message in Application works. Run;
4. Impossibility of control of the flows hanging on synchronize. Other methods of synchronization give such possibility.
First three points no means always depend on the developer. Therefore if someone  with synchronize - another have to suffer or alter.

23

Re: 2 cycles in a flow devour storage

defecator wrote:

it is passed...
For 5 seconds there will be a ten attempts  in a flow;
And the result gets out outside only time in five seconds.
What for to a principal flow generally the nobility what there something such permanently works?

I thought at you  in  time in five seconds becomes.

24

Re: 2 cycles in a flow devour storage

YuRock wrote:

it is passed...
I do not know that there now, but that to D7, it was impossible to use on the big row of the reasons. Fortunately, in it also there is no necessity.
The standard dial-up of a rake synchronize can be seen and most, looking at implementation, well for example:
1. The call synchronize hangs for ever up, if it to cause to Application. Run;
2. Hangs for ever up, if at all call Application was not planned. Run (dll, the console...);
3. Hangs for ever up, if one more operation cycle of messages launched at handling of the message in Application works. Run;
4. Impossibility of control of the flows hanging on synchronize. Other methods of synchronization give such possibility.
First three points no means always depend on the developer. Therefore if someone  with synchronize - another have to suffer or alter.

What passions))))
And after all worked and works

25

Re: 2 cycles in a flow devour storage

YuRock wrote:

3. Hangs for ever up, if one more operation cycle of messages launched at handling of the message in Application works. Run;

*
Not through  HandleMessage.
Or through it, but from dll.