On 19 Jun 2008, at 14:36, Michael Van Canneyt wrote:
On Thu, 19 Jun 2008, Boian Mitov wrote:
Here is a code sniped that sows just one example of the problem:
This is a very simple example of how important the order really is:
We have even more crucial problems related with this. This is just
a simple
one:
destructor TALBasicAudioOut.Destroy();
var
WriteLock : IOWLockSection;
begin
WriteLock := FLock.StopLock();
FInputPin.Free();
FEnablePin.Free();
FMasterPumping.Free();
WriteLock := NIL;
FLock.Free();
inherited;
end;
You can see that the WriteLock MUST be released before the
FLock.Free();,
Maybe Jonas or Florian can comment on this.
Reference counting only guarantees that
a) an instance will not be freed as long as any references to it exist
b) an instance will be freed automatically after the last reference
disappears
It does not guarantee/define
a) at which point in the code exactly an instance will be freed
b) the actual mechanism used for reclaiming the memory (a simple free
when the reference count hits zero, mark and sweep, ...)
It is therefore not a substitute for managing other kinds of resources
which require predictable freeing points. The above example is
conceptually identical to several of the examples given in the
comments to http://bugs.freepascal.org/view.php?id=9472
It's similar to how you cannot use the Finalize method in Java to
perform resource management, because it will only be called when the
garbage collector reaps your instance and not necessarily immediately
when the last reference to an instance is gone.
Jonas
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
