2

Since the process will be killed by OS and all memory allocated will be recycled anyway, is it OK not to free objects/resources in the unit finalization section?

For example,

unit Threading;

interface

implementation

  var threadpool: ThreadPool;

initialization

  threadpool := ThreadPool.Create;

finalization

  threadpool.Free; // is it OK to remove this?

end.
justyy
  • 5,831
  • 4
  • 40
  • 73

3 Answers3

9

Since the process will be killed by OS and all memory allocated will be recycled anyway, is it OK not to free objects/resources in the unit finalization section?

Yes, it is, probably. The system will clean up resources when the process terminates.

However, there are a couple of provisos:

  1. Most leak detection tools check that all dynamically allocated memory is destroyed by your process before it returns control to the system. What you are proposing to do renders such tools impotent.
  2. If your code is ever built into a dynamic library such as a DLL or a package, then the library can be unloaded, whilst the host process endures. This is a leak and can affect the viability of the host process.
  3. Some objects require finalization to occur, sometimes with ordering constraints. Without knowing more about your class, we can't judge that.
David Heffernan
  • 601,492
  • 42
  • 1,072
  • 1,490
  • 3
    To add, there are some scenarios which can be problematic. For example, our own software loads a font dynamically on startup, and has to unload that font on shutdown. If it doesn't properly unload the font, then that font file gets stuck in the memory until the system is rebooted. Even forcefully terminating the process causes it to get stuck. Then, if we need to replace that font file, we can't. – Jerry Dodge Oct 15 '15 at 12:07
  • What if this is a dll and there is still a thread running inside the threadpool? – Sebastian Z Oct 15 '15 at 13:01
  • @Sebastian Indeed. What if? Going to be a disaster. – David Heffernan Oct 15 '15 at 13:02
  • how about FreeLibrary(DLL) in the finalization? – justyy Oct 15 '15 at 13:17
  • @DoctorLai You are not allowed to call FreeLibrary or LoadLibrary in the initialization / finalization part of a dll. – Sebastian Z Oct 15 '15 at 13:45
5

If you remove the Free call from the finalization section then threadpool and all its sub objects will always be present in a memory leak report of your application. It would be hard to find the real memory leaks then.

Some objects may perform logging actions or delete lock files on destroy. So it can be necassary to execute all destructors.

As a (Delphi) developer you should always take care about cleaning up the heap. Otherwise you will probably lose control over the memory management. It can cost you or your company a lot of money to get the control back.

Wosi
  • 41,986
  • 17
  • 75
  • 82
1

Yes, it's ok, but:

1) You can use then following construction:

ThreadPool := ThreadPool.Create;
RegisterExpectedMemoryLeak(ThreadPool);

This approach saves you from mandatory explicit order of unit referencing (so that this unit does not deinitializes before the one which uses it).

2) Otherwise you can nil the variable (or use FreeAndNil if you want System.SysUtils dependency):

finalization
  ThreadPool.Free;
  ThreadPool := nil;

This way you easy find who is accessing ThreadPool when it's released.

3) You can use TInterfacedObject for the implementation or wrapper of the source class.

Z.B.
  • 1,185
  • 9
  • 18