On 8/29/2012 03:59, Lukasz Sokol wrote:
On 29/08/2012 05:05, waldo kitty wrote:
On 8/28/2012 06:47, Bernd wrote:
The pragmatic fix to he above problem was:
procedure TConnection.OnTCPFail(ASocket: TLHandle; const Error: String);
begin
Self._AddRef;
FDisconnectLock.Acquire;
[...]
FDisconnectLock.Release;
Self._Release; //<-- now we will be freed exactly here!
end;
so adding that one line negates the previous .Free line(s)??
i'm still learning all this new-fangled stuff... i'm a (very) oldschool
procedural coder and having things popping into and out of existence whenever
they want to is something i'm still trying to wrap my head around :/ :(
Notice the _AddRef call ?
i didn't then but i do now... my eyes were attracted to the //<-- comment of
which there was none for _AddRef... thanks for pointing it out :)
Thanks to this, the
Self._AddRef;[Self.RefCount is now 2]
[...]
FBuddy.SetIncoming(nil); //[Self.RefCount is now 1] was: bug: this will free
ourselves NOW!!!
<<<<
and after
[...]
Self._Release; // [Self.RefCount is now 0 and GC removes the TConnection from
memory.]
BTW, Frankly, would it not be easier/less error prone if the
FDisconnectLock.[Acquire|Release]
did that ? (i.e. increase/decrease the RefCount of Self as well as
acquire/release the lock ?)
It seems /logically/ correct : there is /one/ more activity associated to this
object, so it
can't be freed before it's done ?
it would seem to be better from my perspective... i can't say that i'll ever
remember to actually write Self._AddRef or Self._Release... remembering to add
the lock will be enough trouble ;)
--
_______________________________________________
Lazarus mailing list
[email protected]
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
