[PyKDE] *very* strange thread error when calling python objects from within C

[Patrick Stinson]

On Sunday 08 February 2004 02:26, Phil Thompson wrote:
> On Sunday 08 February 2004 9:15 am, Patrick Stinson wrote:
> > Actually, I'm not sure what the error really is related to, but I'll try
> > to explain it. I have a C++ library that stores 'Module' objects
> > internally. background thread loops forever and calls 'Produce()' and
> > 'Consume()' in that order on the module objects. The problem is that only
> > recently, that background thread seems to lock itself *and* the parent
> > thread when it calls a Produce() or Consume() on an object that was
> > created in python. Execution never enters the method in question, and the
> > parent thread never returns from a 'time.sleep(2)' python call (which is
> > really freaking me out, btw). Everything works fine if the module object
> > is created from within the C++ code, or if that calling loop is executed
> > from the main thread. I've tried starting the thread from python (using
> > 'thread.start_new_thread()'), and from the C++ library, using pthreads
> > directly. My C++ 'Module' class declares Consume() and Produce as public
> > and virtual void, the subclass defines them as public and void, and the
> > respective definitions in the sip files reflect this exactly (had
> > problems with that stuff before, very frustrating). Sorry that was so
> > long, but I think this problem will require thourough explanation.
>
> I'm not clear - are you wrapping your own C++ thread creation class?
>
> If so, have you specified the /NewThread/ tag to the start method - see
> qthread.sip. Ignore the /CreatesThread/ tag - that's for SIP v3.
>
> Phil


Umm, yes, well actually no. I've wrapped access the Engine class (static 
within my C++ namespace) for simple access, but that object is really a 
global object in my C++ namespace, and the namespace has a GetEngine() for 
it.

More:
My 'Sample : Module' class was completely written in C++, but wrapped in 
python by sip. The C++ class adds itself to the C++ library code that calls 
Produce() and Consume() on that sample in another thread. If I have the C++ 
library create it's own Sample object, thereby avoiding python code 
altogether, everything works fine. Also, if I run the method that contains 
the 'background thread' code from the main thread instead of a new thread 
(like thread.start_new_thread and pthread_create), everything is fine.