On Sat, Feb 25, 2012 at 4:59 PM, L. David Baron <dba...@dbaron.org> wrote:
> Has PyXPCOM been hooked up to the cycle collector yet, or do uses of > APIs that depend on cycle collection just leak memory? david, hi, this had me thinking again. pyxpcom was designed, eek... a decade ago? but i'm not sure it's entirely relevant. the logic goes as follows: * python objects (in c) have their own obj-ref count concept * XPCOM objects also have their own obj-ref count concept (AddRef) which is exactly the same as COM, which "inspired" XPCOM. * when a python object corresponding to an XPCOM object is created, python takes care of adding *one* and *only* one XPCOM object into the c data structure, and calls AddRef *once* and *only* once. * also at the same time, the python object has its PyObject_Ref increased (by one, obviously). * when you need that exact same XPCOM object, if mark hammond didn't program a way to look up the python object which was *already* created to look after it, i'll fall off my bloody chair. * so, assuming that mark is the competent programmer that he is, when you look up an XPCOM object for which a python object already exists, you DO NOT increase the refcount (AddRef) on the XPCOM object, you increase the refcount on the *PYTHON* object. * when the python object's refcount goes to zero, *python's* garbage-collection takes care of destroying the python object, and in the "destructor" function (in the c-based pyxpcom module), that code also performs an XPCOM "Release" call. so with this in mind, i do not see how the "cycle collector" has any relevance, because pyxpcom is merely a direct reflector of the XPCOM objects. but i believe that todd would welcome some input - to todd, who is the de-facto maintainer of pyxpcom - because he, as the de-facto maintainer, would be the person with the most experience in actually sorting it out. esp. if it's a global function that, if not called, results in XPCOM objects not getting properly garbage-collected after the "Release" or something - i don't know, because i don't know what this "cycle collector" is, or what it does. just fyi i went through some... interesting times with webkit's memory management. they don't have anything like XPCOM: it's entirely c++ classes. a massive suite of virtual base classes that derive from a class named "DOMObject". mostly :) at the ultimate lowest level they had to implement the usual "type id" system which lets you externally identify an object even when it's type-cast back down to the absolute lowest object in the hierarchy (gobject has something similar, except they do it entirely in c!). XPCOM and COM both have something similar, except they drop a GUID into the type field. this type id allows you to *BACK*-typecast a c++ object up to its correct (real) class! on top of this, they have c++ refcounting (virtual base class, again). as the concept of XPCOM / COM was entirely missing, they have a templated infrastructure which allows you to map object-of-the-bound-type to object-of-the-webkit-type-when-typecast-down-to-the-base-class-type. then you have to _manually_ provide a massive suite of "upcast" functions which check the type-id and call the next "upcast" function in the chain, after doing a switch statement to get there! all this to handle the one-for-one representation between (say) python objects and webkit's c++ objects, or gobjects and webkit's c++ objects. but even here, you can _still_ do and only need to do one and only one refcount increase on a per-object basis, because once you've gotten into the other side (the bindings), the refcounting of *that* system takes over. so there are close parallels - it's still complicated as hell though :) anyway, do let todd know about this "cycle collection" because i have no idea if he knows about it. l. _______________________________________________ dev-embedding mailing list dev-embedding@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-embedding
