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.
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;