[Solved = False Alarm] Exit from within criticalsection? (application.inc)

[PizzaProgram]

Dear Developers,
 Currently I'm debugging why I can not clean-exit from my app,
   (and eats up +50MB memory / day.)
My program calls 30 parallel processes, (10000/day,) and found this strange code where it stops during app-exit:

Code: Pascal  [Select][+][-]

1. procedure TApplication.ProcessAsyncCallQueue;    
2. ...
3.     repeat
4.       // remove top item from queue
5.       System.EnterCriticalSection(CritSec);
6.       try
7.         if Cur.Top=nil then exit;  
8. ...

IMHO this is fatal, because It will not leave the Critical section ever.
Am I wrong?

Laz v4.4 , FPC 3.2.2

[marcov]

It's wrapped in a try... statement , and you don't show what happens there, but one would expect a finally clause with the donecriticalsection. That runs always, also on EXIT.

[wp]

@PizzaProgram: Please edit the title of this thread: being the author of the fpExif library I am triggered by the "Exif" in the title - please replace it by "Exit"

[Thaddy]

The finally should take care of LeaveCriticalSection.
If it doesn't ...............................

[PizzaProgram]

1. Sorry for bad title, but it is already fixed by someone.
2. Yes, there is a finally ... part of the try, but actually I'm shocked, because I'm using Pascal since 35 years, and I've always thought Exit will exit from the whole procedure or function.
Only the break command does quit from any: for / while / repeat / etc loops.

Is this a FreePascal thing?
 - or is it the same for Delphi 7 too ?

(I'll run a test today for D7)

[Warfley]

Unless you do something very special, the finally section will always be called. If you exit a try block via exit, break, continue or an exception, it will still execute the finally block:

Code: Pascal  [Select][+][-]

1. for i:=0 to 100 do
2.   try
3.     WriteLn('Skipping');
4.     Continue;
5.     WriteLn('This should not be printed');
6.   finally
7.     WriteLn('I is: ', i);
8.   end;
9.  
10. // Or
11. for i:=0 to 100 do
12.   try
13.     WriteLn('Breaking');
14.     Break;
15.     WriteLn('This should not be printed');
16.   finally
17.     WriteLn('I is: ', i);
18.   end;
19.  
20. // Or
21.   try
22.     WriteLn('Exiting');
23.     Exit;
24.     WriteLn('This should not be printed');
25.   finally
26.     WriteLn('Finally is still executed');
27.   end;

[440bx]

Unless you do something very special, the finally section will always be called.

Off hand, the only "very special" thing that comes to mind that would prevent the "finally" part to be executed would be to call an O/S API that causes the program to terminate.

Is there another "very special" thing I'm missing that would cause the "finally" not to execute ?  Maybe calling "Setjump" to resume execution in a different frame ?

[Warfley]

Setjmp or other functions that directly mess with the instruction pointer come to mind. I'm not quire sure about inline assembly but raw jumps should also be able to mess this up. Basically anything that is outside the language.
But more importantly, because the try-finally blocks generate additional context info, if you jump out of them, the Cleanup of that context (it's an internal stack of finally frames) is not performed correctly, which will lead to all sorts of issues

[440bx]

Basically anything that is outside the language.

That's what I thought.

As long as "stack frame disrupting" code is not used, the "finally(s)" should execute.

[Thaddy]

Only the break command does quit from any: for / while / repeat / etc loops.

Is this a FreePascal thing?

Wrong. See warfeley's answer + example.
And no, this is not a freepascal thing: delphi behaves the exact same.

[Xenno]

Statements like exit, break, continue, and goto are often considered harmful and should generally be avoided.

Although my teacher once challenged me, saying, “Why not? Assembler jumps around all the time.”

[440bx]

Statements like exit, break, continue, and goto are often considered harmful and should generally be avoided.

It is highly inappropriate to consider "exit", "break" and "continue" to be in the same league as the genuinely harmful "goto".  Those flow control statements, unlike the "goto" are _not_ harmful.  The reason why should be _obvious_.
\

[MarkMLl]

Statements like exit, break, continue, and goto are often considered harmful and should generally be avoided.

It is highly inappropriate to consider "exit", "break" and "continue" to be in the same league as the genuinely harmful "goto".  Those flow control statements, unlike the "goto" are _not_ harmful.  The reason why should be _obvious_.
\

This is OT from the original question but there is a substantial body of opinion which /does/ equate  exit  etc. with  goto.

This is particularly the case when array processing is concerned, since there's a risk that flow control attempts to apply to one part of the array but not the remainder. That's why at a mathematical level one sometimes sees what would appear (to a programmer's eyes) to be quite weird application of transcendentals etc.

The doctrinal deviation exists, whether or not one agrees with it. I certainly have reservations, and feel that there would be a good argument for explicitly marking code bodies that contained anything like that as frangible, i.e. incautious use might break something /if/ used for array processing etc.

MarkMLl

[440bx]

This is OT from the original question but there is a substantial body of opinion which /does/ equate  exit  etc. with  goto.

You're right, it is OT.  The problem is, there is at least one CRUCIAL difference between "break", "continue", "exit" and "goto".  Those who put them in the same class simply lack the understanding of some very basic programming concepts. 

The only thing those statements have in common with the "goto" is that they are all flow control statements and, if that's a "problem" for someone then, they should include "for", "while", "repeat", etc, which I hope the absurdity of their inclusion is obvious (if not painfully obvious.)

[Xenno]

Not really OT. For short code it might easy to follow but the habbit might cause issues on longer code.

It could be written like this:

Code: Pascal  [Select][+][-]

1. ...
2.     CanContinue := True;
3.     repeat
4.       // remove top item from queue
5.       System.EnterCriticalSection(CritSec);
6.       try
7.         if Cur.Top <> nil then begin
8.           ...
9.         end else
10.           CanContinue := False;
11.       finally
12.         System.LeaveCriticalSection(CritSec);
13.       end;
14.     until not(CanContinue) or (OtherConds);      
15. ...

The flow will be clearer.

exit, break, continue, goto are for machine. They are not for humans. The common reason for using them are to do shortcuts (or shorter code).

Luckily Pascal does not need break in a case statement.