TTask 'file not found' error

[sollapse]

When testing TTask functionality, I get a strange error only within an FCL GUI app that states 'RunError(103) file not found'. TTask works normally within a console application. Is this expected behavior at the moment?

For example

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

1.  
2. TTask.Run(procedure
3.   begin
4.     ShowMessage('test');
5.   end);
6.  

[Thaddy]

103 means that stdOut is not present.
Add {$apptype console} to your GUI app as a workaround.
That will create IO handles for the console.
Where did you get your TTask? Which unit?
You may want to redirect your stdout to the a GUI component.
That will also work.

See e.g. this example from Howardpc
https://forum.lazarus.freepascal.org/index.php/topic,34621.msg227290.html#msg227290

But without your particular TTask I can do little more.

[sollapse]

Okay, that makes sense. I'm using the implementation that is in System.Threading with the 3.3.1 trunk compiler.

[Thaddy]

OK:
It is not so nicely written, because the unit uses writeln for debug .
Disable DEBUGTHREADPOOL:

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

1. {$UNDEF DEBUGTHREADPOOL}

Or re-apply the double {{ istead of the single {
Then everything will be OK.

There is only one place where that causes a writeln. (and so a 103)
So you probably inadvertedly enabled DEBUGTHREADPOOL.
If you do so, you must also add {$APPTYPE CONSOLE} in the main project file to see the debug output.
I just tested that.

[EDIT]
More work to do...at least on Windows.
There is still a misuse of the console in either system.threading, fpthreadpool, etc that is not governed by debug settings. We have to find and report the culprit, because that is a bug.
It is probably an rtl bug but it can also be a lazarus bug.

[sollapse]

Thank you for informing me about this. I also stumbled across another potential bug. It came about when trying to use the Async/Await interface as posted here https://www.thedelphigeek.com/2012/07/asyncawait-in-delphi.html. Since I'm getting a lot of access exceptions from the passed procedure references, I don't know if there's a problem with how function references are captured.

I've put up a bug link on GitLab https://gitlab.com/freepascal.org/fpc/source/-/issues?show=eyJpaWQiOiI0MTI5NyIsImZ1bGxfcGF0aCI6ImZyZWVwYXNjYWwub3JnL2ZwYy9zb3VyY2UiLCJpZCI6MTY5MzEyMzQ1fQ%3D%3D.

[Thaddy]

The problem also exist when I port your code to a terminal. Both in Windows (endless loop) and Linux (AV).

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

1. // crashes in both Win64 and Linux64.
2. {$apptype console}
3. {$mode objfpc}
4. {$modeswitch functionreferences}
5. {$modeswitch anonymousfunctions}
6. {$modeswitch implicitfunctionspecialization}
7.  
8. uses system.threading;
9.  
10. procedure ShowMessage(const value:string);
11. begin
12.   writeln(value);
13. end;
14. var
15.   Task:ITask;
16. begin
17.   Task := TTask.Run(procedure
18.             begin
19.               Showmessage('Test');
20.             end);
21. end.

This means that it has probably nothing to do with StdOut

The GUI version also crashes in both Linux64 and Linux.
Are we using the class method  TTask.Run() wrong? Even if we take care of the result?

[sollapse]

I'm able to use this code in the GUI app fine with the redirection of stdout. The Dialogs unit has to be included for ShowMessage. For a console test, I replace the message dialog with WriteLn instead.

[Thaddy]

Yes, I can get the GUI to work, as I suggested in my first post.
I can't get the console to work though, not even with this code:

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

1. {$if fpc_fullversion < 30301}{$error needs fpc 3.3.1 or later}{$ifend}
2. {$apptype console}
3. {$mode objfpc}
4. {$modeswitch functionreferences}
5. {$modeswitch anonymousfunctions}
6. {$modeswitch implicitfunctionspecialization}
7.  
8. uses system.threading;
9.  
10. procedure ShowMessage(const value:string);
11. begin
12.   writeln(value);
13. end;
14.  
15. var
16.   Task:ITask;
17. begin
18.   Task := TTask.Create(procedure
19.             begin
20.               Showmessage('Test');
21.             end);
22.   Task.Start;
23. end.

Which is similar, but doesn't use class methods,

[sollapse]

Yes, I can get the GUI to work, as I suggested in my first post.
I can't get the console to work though, not even with this code:

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

1. {$if fpc_fullversion < 30301}{$error needs fpc 3.3.1 or later}{$ifend}
2. {$apptype console}
3. {$mode objfpc}
4. {$modeswitch functionreferences}
5. {$modeswitch anonymousfunctions}
6. {$modeswitch implicitfunctionspecialization}
7.  
8. uses system.threading;
9.  
10. procedure ShowMessage(const value:string);
11. begin
12.   writeln(value);
13. end;
14.  
15. var
16.   Task:ITask;
17. begin
18.   Task := TTask.Create(procedure
19.             begin
20.               Showmessage('Test');
21.             end);
22.   Task.Start;
23. end.

Which is similar, but doesn't use class methods,

I'm sorry, it's been a pretty long night for me and I glanced over your previous code the first time. Yes, I confirm this same code freezes as well for me.

The following version works for me however

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

1. program Project1;
2.  
3. {$mode objfpc}{$H+}
4. {$modeswitch functionreferences}
5. {$modeswitch anonymousfunctions}
6.  
7. uses
8.   {$IFDEF UNIX}
9.   cthreads,
10.   {$ENDIF}
11.   Classes,
12.   SysUtils,
13.   System.Threading { you can add units after this };
14.  
15.   procedure ShowMessage(const Value: String);
16.   begin
17.     writeln(Value);
18.   end;
19.  
20. var
21.   Task: ITask;
22. begin
23.  
24.   Task := TTask.Create(procedure
25.   begin
26.     ShowMessage('Test');
27.   end);
28. Task.Start;
29.  
30. ReadLn;
31. end.

[sollapse]

This also seems related to my implementation of the Async/Await class. I've noticed the class will crash if a function is not added under the call. It seems that using ReadLn in the console example allows the task to run.

[Thaddy]

readln is indeed necessary in windows applications run under Lazarus. It works without in other editors, like Geany.