Re: FW: Object Lifetime Management with Boost-Python V2

8 Nov 2002

      "Daniel Paull"  writes:

Please post Boost.Python questions to the C++-sig:

http://www.python.org/sigs/c++-sig/
...
Hi all,
I'm having trouble with some object lifetime issues using Boost Python
V2.  Basically, I'm in a situation where both C++ and Python want to
delete the same object.
...
Below is a simple example of the scenario.  Consider the two classes A
and B.  An instance of A is passed to B via the setA() method.  B then
assumes ownership of A and deletes it in it's destructor.  NOTE: the
behaviour of the C++ code can not be changed currently.
-------------------------------------
class A
{
public:
  A() {}
  ~A() {}
};
class B
{
public:
  B() : m_a( 0 ) {}
  ~B(){	if ( m_a ) delete m_a; }
  void setA( A* a ){ m_a = a; }
private:
  A* m_a;
};
---------------------------------------
I have defined a python module thus, being sure to indicate the pointer
adoption by using the with_custodian_and_ward<> policy:
---------------------------------------
BOOST_PYTHON_MODULE( my_module )
{	
  class_< A >( "A" )
      ;
class_< B >( "B" )
      .def( "setA", &B::setA, with_custodian_and_ward<1, 2>()
)
      ;
}
---------------------------------------
What that says is, "keep the /Python/ A object alive as long as the
/Python/ B object is alive". This can't save you from deleting the C++
A object out-from-under the Python A object.
...
All is fine, and I can show that instances of B keep their instance of A
alive.
However, executing the python code:
--------------
a = A()
b = B()
b.setA()
--------------
results in "a" (or rather, the wrapped C++ object) being deleted twice.
There's currently no good way to express what you want in
Boost.Python. As you can see from
http://aspn.activestate.com/ASPN/Mail/Message/1400931 and the ensuing
thread, my best solution to-date is to suggest that you hold the C++
object by shared_ptr and use shared ownership. Clearly, if you can't
change the C++ code you're wrapping, that won't work for you.

I think a new call policy which actually causes the Python A object to
/release/ its ownership of the C++ A object might be useful here. I'll
put this on my list of to-dos. In that case, there would be no reason
to keep the Python object alive, since it's no longer managing the
lifetime of the contained object. Obviously, you'd need to wrap your
class with some sort of smart pointer holder as well:

        class_("A")
                  ;

So that ownership could eventually be released. Otherwise, the C++
object's memory is embedded in the Python object's memory, and you
can't use 'delete' on that address.

I'll be working on Boost.Python next week, and will put your problem
on my list of TODOs.
...
I can get around this problem by using a free function "createA()"
which returns a new instance of "A" using the
"return_existing_object" return value policy,
How does this help?
...
but this seems dangerous and can introduce a memory leak if the user
does this from python:
--------------
def makeLeak():
  a = createA()
makeLeak()
--------------
Perhaps a new call policy is the solution, but I'm not sure how to
proceed.  Has anyone solved this problem already?
If createA is doing `new A' (please don't make me guess!) then
return_existing_object is not the right policy; you'd want
manage_new_object. However, I still don't see how that could solve any
of your problems.

-- 
                       David Abrahams
   dave@boost-consulting.com * http://www.boost-consulting.com
Boost support, enhancements, training, and commercial distribution