On 05/07/2012 11:30 AM, Adam Preble wrote:
I want to make sure I understand the repercussions.
I understand if I were introducing C++ objects into the Python runtime as
internal references that I would be inviting disaster if I delete them on
the C++ side, but continue to use them on the Python side. I don't think
either of us were talking about that but I wanted to make sure I understood
the boundaries here.
Now on to shared pointer references. I am utilizing shared pointers for
this particular circumstance. The object was created in Python and went
out of scope. If it weren't for the shared pointer, that would be the end
of it, but the pointer was passed to my C++ runtime and retained in a data
structure for future work. This kept it alive--as I had desired. When the
object eventually leaves that structure and the refcount drops to zero, it
moves on to destruction.
It does look to me like Python is trying to take care of it since I
immediately pile up through a bunch of Python runtime functions before I
eventually hit my favorite "no such thread" GIL error in the runtime.
You may want to inspect the shared_ptr's deleter object, if you can
figure out a way to do that (i.e. see if it is a
boost::python::converter::shared_ptr_deleter). It seems possible that
you aren't (for some reason) getting a "native" C++ shared_ptr, but
rather one that holds a Python object in its custom deleter, and
invoking that Python thing's destructor is what's causing your problem.
Jim
_______________________________________________
Cplusplus-sig mailing list
Cplusplus-sig@python.org
http://mail.python.org/mailman/listinfo/cplusplus-sig
