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

[Patrick Stinson]

On Monday 09 February 2004 17:24, Patrick Stinson wrote:
> 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.
>
> _______________________________________________
> PyKDE mailing list    PyKDE at mats.imk.fraunhofer.de
> http://mats.imk.fraunhofer.de/mailman/listinfo/pykde


I rolled back to sip3.8 (from above version) to try out the lib, and it fixed 
the problem. Suppose this would end up being an interesting bug for the 
log...