patrickkidd at gci.net
Mon Aug 9 10:51:00 BST 2004
sorry, I'd copy the original message, but I haven't been getting much mail
lately for some reason.
Anyway, Phil, in response to you suggesting I 'compile with tracing enabled',
I've done it with PyQt, but my problem lies with my sip-generated module
wrapping my C++ library, and there isn't an option for compiling with
tracing. What sort of 'tracing' would that be, anyway?
Here is the original message:
On Sunday 01 August 2004 9:56 pm, Patrick wrote:
> I've run into a problem with virtual functions and sip-4. The problem does
> not exist in sip-3.
> I have a superclass with a (non-pure) virtual function, and a couple of
> subclasses that re-implement it. I create an object or two of the
> subclasses and register them with my C++ library through an exposed python
> method. My C++ code then calls the virtual functions, which are *not*
> reimplemented in python.
> The problem is that when sip_api_is_py_method is called, that thread stops
> when it tries to acquire the GIL. I have checked that don't have ANY calls
> from C++ into python via virtual methods (which is where another thread
> could have acquired the lock and not returned),
> Where else should I look, and would this be some sort of a bug or another
> caveat for using C++ bindings?
I'd rebuild with tracing enabled to make absolutely sure what's actually being
called and when.
If sip_api_is_py_method() is blocking then it must be in the call to
PyGILState_Ensure(). The latter is a small function so it should be easy to
add debug statements to it and see exactly what's going on.
More information about the PyQt