[PyKDE] Re: [C++-sig] Can boost.python and PyQt be used together?

[David Abrahams]

"Paul F. Kunz" <Paul_Kunz at SLAC.Stanford.EDU> writes:

>    Its me again.   This time, I've got my Python extension modules
> working completely with Boost.Python wrapped alone.   That is...
>
> [pfkeb at Kunz-pbdsl1 testsuite]$ python
> Python 2.2.2 (#1, Oct 15 2002, 07:42:56) 
> [GCC 2.95.3 20010315 (release)] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
>>>> from hippo import *
>>>> app = HDApp(1)
>>>> cw = CanvasWindow()
>>>> cw.show()
>>>> app.exec_loop()
>
> works fine.   In the above, `HDApp' is not derived from
> QApplication, but delegates to a class which does.   CanvasWindow
> wraps a C++ class which derives from QMainWindow.
>
> Now I modify the dclock.py example that comes with PyQt to...

Hmm, does dclock.py by any chance use threads?

> a = QApplication(sys.argv)
> clock = DigitalClock()
> clock.resize(170,80)
> a.setMainWidget(clock)
> clock.show()
>
> cw = CanvasWindow() # added
> cw.show()           # added
>
> a.exec_loop()
>
> and get ...
>
> Starting program: /usr/local/bin/python /home/pfkeb/hippodraw-BUILD/testsuite/dclock.py
> [New Thread 1024 (LWP 5948)]
>
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 1024 (LWP 5948)]
> PyErr_SetObject (exception=0x8108a8c, value=0x81ab208) at Python/errors.c:39
> (gdb) bt

<snip>

> (gdb) 
>  
>    On the line of the error
>
> 	oldtype = tstate->curexc_type;
>
> (gdb) p tstate
> $1 = (PyThreadState *) 0x0
> (gdb) 


Well, the thread state is NULL. I don't know what this means, but I
think it's premature to conclude that SIP and Boost.Python are
incompatible with one another. As far as I can tell, they should not
interact in any particular way, any more than Boost.Python should
interact with, say, the CPickle extension module which comes with
Python's standard library.

I know relatively little about Python threading, except that only one
thread may be executing core Python code at any given time. That means
that if your C++ code is being called from multiple threads it must
acquire something called the global interpreter lock (GIL) before it
touches any Python objects. If you have any virtual function
dispatching back to Python going on in your C++ objects (i.e. using
call_method), you could easily be running into this issue.

-- 
                       David Abrahams
   dave at boost-consulting.com * http://www.boost-consulting.com
Boost support, enhancements, training, and commercial distribution