[C++-sig] GIL problems during destruction of a boost::python::wrapper
talljimbo at gmail.com
Mon May 7 20:38:31 CEST 2012
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.
More information about the Cplusplus-sig