[PyKDE] sip_is_py_method

[Patrick]

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.

Phil