[PyKDE] sip_api_is_py_method

[Phil Thompson]

On Tuesday 24 August 2004 6:52 am, Patrick Stinson wrote:
> 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.
>
> > 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.

If you are using the thread/threading modules to start your threads (instead 
of QThread) then try the patch to Python that I posted recently.

Phil