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