[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