[prev in list] [next in list] [prev in thread] [next in thread] 

List:       pykde
Subject:    RE: [PyKDE] Help with SIP
From:       "Claus, Richard" <claus () slac ! stanford ! edu>
Date:       2004-12-23 20:52:46
Message-ID: 35C208A168A04B4EB99D1E13F2A4DB0120C825 () exch-mail1 ! win ! slac ! stanford ! edu
[Download RAW message or body]

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@riverbankcomputing.co.uk]
Sent: Wed 12/22/2004 11:53 PM
To: pykde@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


_______________________________________________
PyKDE mailing list    PyKDE@mats.imk.fraunhofer.de
http://mats.imk.fraunhofer.de/mailman/listinfo/pykde


[prev in list] [next in list] [prev in thread] [next in thread]