UPDATE: The issue described here has been marked „resolved“ on May, 5th 2017, so we should see corrected behaviour in one of the next deliveries.
I am using TTask.Run quite a lot in projects and in many of my demos. I won’t go into the details of how to use TTask here, but I only want to highlight that there is still an open issue, which may cause interfaced objects to be destroyed much later, than you would expect. Ultimately this may lead to a much higher memory footprint of your application.
As of Delphi 10.1 Update 2 the issue is still marked open on quality.emabaracdero.com – you might vote for it, if your code is affected by it.
Interfaced objects use automatic reference counting for lifecycle management:
var
LFoo : IFoo
begin
LFoo := TFoo.Create;
//work with LFoo
end; //LFoo goes out of scope, its reference counter will go to zero,
// thus it will be destroyed here automatically.
With TTask.Run you can start background threads, that will execute code passed in as anonymous method:
var
LFoo : IFoo
begin
LFoo := TFoo.Create;
TTask.Run(procedure
begin
Foobar(LFoo); //Work with LFoo
end;
).Waitfor; //Wait for task/thread to be completed
end; //LFoo goes out of scope, its reference counter SHOULD go to zero,
// thus it SHOULD be destroyed here automatically.
Unfortunately the above does not work as expected. The internals of TTask (actually TThreadpool) keep a reference to the (already finished) task and prevent the instance of TFoo, which is referenced by LFoo, to be destroyed automatically. At least when the TThreadPool gets destroyed, all those kept references will be released and the instances will be destroyed, thus they won’t report as memory leak (with ReportMemoryLeaksOnShutDown).
In other words: you will have to set LFoo to nil manually – until this issue gets solved in one of the next updates.
TTask.Run(procedure
begin
Foobar(LFoo); //Work with LFoo
end;
).Waitfor; //Wait for task/thread to be completed
LFoo := nil; //Depending on your logic, this could also be done inside TTask.Run
end;
