[PyKDE] Help with SIP
Claus, Richard
claus at slac.stanford.edu
Thu Dec 23 20:52:46 GMT 2004
The C++ part of my module is a collection of iterators over, and accessors to a buffer of data. It doesn't depend on any other packages (e.g. Qt). SIP is used to provide an interface to this package from Python. In some Python environments, the result is a single threaded program, not using Qt, PyQt, etc. In other environments, my package is used in the presence of Qt, PyQt, and various other packages. In order to keep Qt GUI screen updates crisp, we've seperated that application into multiple Python threads. The one Qthread we have is used for communicating GUI requests from a Python thread to the GUI thread. My module is run purely from one of the Python threads.
There is some small amount of handwritten SIP code, yes, although it was signficantly reduced in the move from SIP 3 to 4.
No, there are no threads or other system calls in the package itself. However, users may resolve some of the module's virtual methods with Python code that does use system calls or functions that affect the GIL. Prints in the SIP generated cpp and a test virtual method don't appear in the non -g case, so it's not getting far enough to exercise problems caused by such user code.
BTW, I forgot to ask how to use SIP's debug printing option (-r). Naively turning it on doesn't show anything on stdout. Is there a run-time flag that must be enabled? I don't see it described in the SIP documentation.
One fly in the ointment that may affect this discussion is that the C++ class in which the problem occurs is derived from an abstract base class. The derived class provides implementations for the base class's pure virtual methods, in addition to other functionality. Both the derived class and the base class are exposed to Python with SIP since in some applications one wants the one and in others the other. The derived class and the base class have their own SIP files which don't contain any handwritten SIP code. Oddly, I found that I had to declare the pure virtual methods of the base class that were resolved by the C++ derived class, and thus no longer needing exposure to Python, in the SIP code or they wouldn't be called. When SIPed without -g, I see that a print in one of these C++ resolved virtual methods doesn't appear before the hang, so I unfortunately misspoke in my previous post. With the -g, it does appear.
Thanks,
Ric
________________________________
From: Phil Thompson [mailto:phil at riverbankcomputing.co.uk]
Sent: Wed 12/22/2004 11:53 PM
To: pykde at mats.imk.fraunhofer.de
Cc: Claus, Richard
Subject: Re: [PyKDE] Help with SIP
On Thursday 23 December 2004 1:18 am, Claus, Richard wrote:
> I've built a package using C++ and SIP 4.1.1 (on both Windows XP and Linux)
> that can be imported and used from Python 2.3.4. In a single threaded
> environment, without PyQt, it works as expected. In a multi-threaded
> environment with PyQt, I observe the following: 1) When the package is
> built using SIP without the -g option, the program hangs at the point of
> calling the first virtual method resolved by a Python method. The PyQt GUI
> is no longer updated or redrawn and the program must be killed. 2) When the
> package is built using SIP with -g option, the program appears to run
> correctly, but sooner or later a bomb box (on XP) appears with the Python
> message "this thread state must be current when releasing".
>
> Can someone please offer some suggestions on how to debug this?
Is there any handwritten code in your module? Does the package use threads
itself? What do you mean by a multi-threaded environment - compiled against
qt-mt rather that qt, or in an application that starts multiple threads?
Phil
More information about the PyQt
mailing list