[C++-sig] Fatal Python errors related to virtual methods

[David Abrahams]

Patrick Hartling <patrick at vrac.iastate.edu> writes:

> The C++ application framework I am mixing with Python is
> multi-threaded, and the Python object has its methods invoked from a
> spawned thread (as is evident from the stack trace above).  I saw a
> message or two on comp.lang.python that led me to believe that threads
> may be an issue.  I don't know for sure, though.

It certainly is /an/ issue.  Can't say for sure if it's /the/ issue.

Here's what you need to do, in a nutshell:

       Any place that call_method<...>(...) can be invoked on a
       thread that isn't the thread running the Python interpreter,
       you need to surround it with macro invocations which acquire
       the Global Interpreter Lock (GIL) and establishes the thread
       state (and then subsequently release it):

   http://www.python.org/dev/doc/devel/api/threads.html#l2h-751
   has a description.

       It looks as though you'll need to save away a copy of the
       thread state in your module initialization function or
       something to accomplish the above.

       Any place that you a wrapping a function which might invoke
       such a surrounded call_method<...> invocation, you must release
       the GIL and then subsequently acquire it.  You can do this by
       wrapping a "thin wrapper" function which just adds the
       neccessary GIL management.

   Adding the ability to do this stuff automatically (so you don't
   have to do as much of it by hand) globally for an extension module
   or on a function-by-function basis is something I've been meaning
   to get to for a while.  If you figure out the formula, we'll have a
   head start at integrating the functionality into Boost.Python.

HTH,
-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com