[Lazarus] Delphi post-XE3 roadmap

[waldo kitty]

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