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 _______________________________________________ PyKDE mailing list [EMAIL PROTECTED] http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
