[Lazarus] Delphi post-XE3 roadmap

[Lukasz Sokol]

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 ? 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 ?

Curiously,
L.