On 29/08/2012 11:11, Bernd wrote: > 2012/8/29 Lukasz Sokol <[email protected]>: > >> 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 ? > > Yes, you are right, that would consequently be the most logical > place for these calls. It was just a pragmatic quick fix to narrow > down the source of the problem. I'm not yet 100% satisfied with this > entire connection object and everything that surrounds it (and the > multiple ways it must be able to end its life: it must be able to > free itself (happens on the network thread) and it must be able to be > disconnected and freed from the outside from the main thread). > Athough now it seems that all crashes are gone I somehow still don't > really like the code yet. >
Well. >From before I remember even in Delphi (maybe), calling Self.Free, or >equivalent, even as a last line ever, was an invitation to memory corruption and AV's. (LCL/VCL Forms come as example : you don't free one from within, period. You call Close, and OnClose you decide if you want to Hide it or whatsit-called-option-to-destroy - but only the parent was able to free its child - in this instance, Application's Idle loop (again, IIRC).) So I imagine Object Pascal way would be to have the TConnection as a child of some governing object, that would only ever call its .Free destructor, and of itself never getting destroyed (the governor). And I see where the temptation to include the /common/ cases of such constructs into a Garbage Collector comes from... in programs without TApplication. (again all this is IIRC and IMVHO) (I sense we got a bit OT?) L. -- _______________________________________________ Lazarus mailing list [email protected] http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
