[PyKDE] Re: How do I fix this?

[Phil Thompson]

ian reinhart geiser wrote:
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On Saturday 16 February 2002 05:16 am, Phil Thompson wrote about [PyKDE] Re:
> How do I fix this?:
> > ian reinhart geiser wrote:
> > > -----BEGIN PGP SIGNED MESSAGE-----
> > > Hash: SHA1
> > >
> > > Greetings
> > > I have a situation where I am wrapping a class that handles its instances
> > > internally  Basicly when i create a new object as follows:
> > >         myObject(parent, name)
> > >
> > > The parent manages the instance and the instance is kept in the parents
> > > internal lookup table.  The problem is at the end of the function python
> > > cleans the myObject instance up.  Is there a way to keep python from
> > > killing these objects, but still allow me to delete them from C++?
> >
> > Use the /TransferThis/ option on the parent argument. Look at the .sip
> > file for any PyQt class that is derived from QObject.
> >
> > The result is that the generated code transfers ownership (ie.
> > responsibility for calling the dtor) for the new instance to the parent
> > object (so long as the parent object is non-zero).
> 
> Ah now I have another problem.  It seems when I delete the parent there is a
> race condition between python removeing my object for me and my memory
> cleanup.  About 75% of the time python wins and I get QObject double object
> deletion warning, but on the 25% of the time that python loses the object is
> deleted and python has a conniption.  Is there a way to force python to just
> deal, and assume I know what i am doing?  I have seen talk of this before
> about adding a PY_XINCREF in your sip file for the constructor of the object
> and a PY_XDECREF of the destructor.  Is this correct?

Python shouldn't be calling the dtor of the child C++ instances with
/TransferThis/ specified. Or are you saying the race is when deleting
the parent?

Is the parent a different class from the children? Does the parent
derive from QObject? Have you applied /TransferThis/ *everywhere* it is
needed?

Incrementing the reference count in the ctor just means the dtor will
never be called and you've created a memory leak.

Phil