[C++-sig] Deriving Python function from C++ base class with pure virtual function

Paul F. Kunz Paul_Kunz at slac.stanford.edu
Thu Dec 2 17:34:47 CET 2004


>>>>> On Sun, 14 Nov 2004 17:35:14 -0500, Jonathan Brandmeyer <jbrandmeyer at earthlink.net> said:

> See the PEP 311 interface PyGILState_Ensure()/PyGILState_Release(),
> which you will use to wrap around the callback function in your C++
> code.  This interface solves the thread bootstrap problem.
> Furthermore, the lock is recursive, so locking the GIL is safe when
> you already have the lock.

   I tried this with Boost-1.32.0 and Python 2.4 as follows...

double
FunctionWrap::
operator () ( double x ) const
{
  PyGILState_STATE state = PyGILState_Ensure ();
  double value =  call_method < double, double > ( m_self, "valueAt", x );
  PyGILState_Release ( state );

  return value;
}

I still get SIGSEGV with different traceback as follows...

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1117453104 (LWP 16757)]
0x40030dca in sem_post at GLIBC_2.0 () from /lib/tls/libpthread.so.0
(gdb) up
#1  0x080e7be1 in PyThread_release_lock (lock=0x0) at thread_pthread.h:332
332	in thread_pthread.h
(gdb) up
#2  0x080b5cd3 in PyEval_ReleaseLock () at Python/ceval.c:234
(gdb) 
#3  0x080e1b63 in PyGILState_Release (oldstate=142794840)
    at Python/pystate.c:264
(gdb) 
#4  0x407ffb8e in FunctionWrap::operator() (this=0x0, x=0)
    at ../../hippodraw/python/FunctionWrap.cxx:113
Current language:  auto; currently c++
(gdb) 

Note `lock=0x0' in the call to release_lock.

   Any suggestions?



More information about the Cplusplus-sig mailing list