[Kde-bindings] GC system inside kde-bindings

[Richard Dale]

On Thursday 19 July 2007, Dongxu Ma wrote:
> >On Wednesday 18 July 2007, Dongxu Ma wrote:
> >> Hello Richard, CC: gents,
> >>
> >> Beside object bus, how do you deal with allocation of Qt/Kde object ?
> >> First I'd like to share you my progress on my QT4 Perl binding. Due to
> >> personal issues, I recently didn't pay much time on coding...
> >> The typemap system is almost finished. You can check here (
> >> http://dongxu.googlecode.com/svn/trunk/PerlQT/script/create_typemap.pl)
> >> The typemap, as you know in perl, is the repos for type marshalling
>
> between
>
> >> perl and c++ plants. While the old typemap mechanism introduced by
> >> ExtUtil.pm is somewhat out of date, it has no knowledge about
>
> relationship
>
> >> between relevant types. Say, for instance, QString and QString *.
> >> Typemap simply treats them as un-relevant ones.
> >> What I did in tha script is a knowledge study and relationship analyse
> >> system. For above example, in case it knows QString is a QObject
>
> (obviously
>
> >> from qstring.h), it automatically knows how to marshall QString *,
>
> QString
>
> >> &, const QString, const QString * and QString const *. Furtherly
> >> QList<QString *> is possible. It goes thru different aspects to find
> >> type relationship ( class declaration, inheritance tree, namespace path,
> >> pre-defined typemaps ).
> >> It is powerful enough to bridge native Qt type with KDE type, custom
>
> type.
>
> >Well I think we already have this sort of thing in the Smoke libs, and we
>
> have
>
> >a parser written in perl with powerful abstract syntax tree utilities for
> >walking round the parse tree.
>
> Nice. I used to have a look at Smoke, the output is quite programmatic look
> (in C),
> that is one of the primary reasons I'd like to write QTEDI, which presents
> in more
> human-readable style. While that doesn't mean Smoke is ugly, really depends
> on
> how people make use of.
Well I don't think that being able to read the autogenerated code is all that 
important. Nobody is going to read 1000s of lines of yaml either. You can 
introspect the smoke lib to ask what classes and methods it has though, which 
is certainly useful, and something you can't do in any other language binding 
library as far as I know.

> >> While the bad situation I am facing is GC system. Perl uses simple
> >> reference, while ruby makes use of mark and sleep way. On the another
>
> hand,
>
> >> generally, various cases may mess GC:
> >> 1) GC in Qt itself: Qt maintains its internal object reference status;
> >> 2) non-new method which exports an internal address,which will have the
> >> same lifecycle of exporter;
> >> 3) non-new method which returns a new heap address, which transfers the
> >> ownership of that pointer to caller;
> >> 4) non-new method which accepts a pointer and takes the ownership of
> >> that pointer;
> >>
> >> Either case will leak the vm unless treating it carefully.
> >> I'd like to hear your words on this question.
> >
> >The Smoke bindings have a struct like this:
> >
> >struct smokeqyoto_object {
> >   bool allocated;
> >    Smoke *smoke;
> >   int classId;
> >   void *ptr;
> >};
> >
> >Where 'allocated' is true if the instance was created in the bindings
> >language, and so the bindings runtime is responsible for deleting the C++
> >instance on garbage collection.
> >
> >The bindings runtime needs to know about the various rules of object
>
> ownership
>
> >in the Qt libraries such as the QObject object tree where a parent 'owns'
>
> its
>
> >children and is responsible for deleting them.
> >
> >The QtJambi bindings have a third state, which is 'not owned by either c++
>
> or
>
> >the bindings language'.
>
> The hard point here is the handover of object relationship is really case
> by case.
> The metaobject system in Qt is mainly based on class inheritance hierarchy.
> That doesn't really work for the case: the instance exports an inner part
> (note
> that such part is in-a-class, not is-a-class); while other method may
> export a
> component of itself, which is certainly a standard QObject, and release the
> ownership of that component to caller; From my point of view, it is very
> hard to
> tell such two different cases automatically.
> Another example to address one of my previous points: say, one creates a
> new
>
> QObject in binding code, then QObject is owned by binding code till a
> special
> method is invoked, which takes that QObject as parameter and finally 'eats'
> it.
> That dedicated QObject is taken over by Qt metaobject after the call,
> regarding
> its lifecycle.
> You can find such method somewhere inside Qt (sorry, I don't remember the
> class
> name but I am pretty sure it has).
> The issue here is Qt metaobject system doesn't offer any callbacks on the
> events
> of importing/exporting a child. A message bus between Qt and bindings.
> There is QObjectCleanupHandler, not very helpful in this paticular case.
> Things go more complex if we start talking about non-meta classes (which is
> declared without Q_OBJECT macro). This side is completely out of control
> from
> Qt metaobject system.
Yes,  there is an internal method for monitoring changes in QObject parents 
via events. From qyoto.cpp:

QInternal::registerCallback(QInternal::EventNotifyCallback, 
qyoto_event_notify);

Then qyoto_event_notify() is sent events:

static bool 
qyoto_event_notify(void **data)
{
    QEvent *event = (QEvent *) data[1];

	// If a child has been given a parent then make a global ref to it, to 
prevent
	// garbage collection. If a parent has been removed, then remove to global 
ref
	// to the child also.
	if (event->type() == QEvent::ChildAdded || event->type() == 
QEvent::ChildRemoved) {
...


> >> PS: boost python binding page also discussed similar issues. Go and take
>
> a
>
> >> look.
> >
> >What will it tell us that we don't already know, and what do you think is
> >wrong with out existing approaches?
>
> Trust me, I am really not arguing current kde-bindings' implementation ;-)
> Please don't treat me like an enermy ;D
> I pay my enough respect to you guys behind this maillist, indeed.
> Noticed that recently there was a post saying different words on
> kdeveloper.org.
> I think the author was quite friendly and really wanted to bring new ideas
> in.
> Things are always improved by questions and innovations.
> We can keep walking on each own way but we can share our thoughts, right ?
Sorry if I sounded rude. It's more that I'm not sure if you've studied the 
code for the existing Qt bindings enough. Unless you can understand what they 
do, and how they do it, then it will be very difficult to design something 
better. You'll probably just end up re-inventing what we already have. So 
maybe boost python have done something none of the bindings authors (ie the 
QtJambi, PyQt, QtRuby, PerlQt, Qyoto and PHPQt authors) have thought of.


> >Note that the subject of this thread is 'splitting up the smoke libraries'
>
> -
>
> >please can you start a new thread to discuss anything which isn't about
>
> that
>
> >topic?
>
> Sorry, that topic triggered me yesterday.
OK, no problem - it just easier for people to follow the history of the 
discussion in the if we can keep the threads a bit self contained.

-- Richard