Not played with Python 2.3...still working with 2.2. But are you basically staying I should have a Thread State per Thread, as opposed to how I actually have it...with a Thread State per Callback? Just to point out the version you are looking at seems to work....we have had uptimes in the of 2 weeks+, then the system shutsdown due to other valid reasons. Initially we tried 'stealing' the main python threads Thread State and forcing a function call...nasty I know but it seemed to work...for about 37 hours, problem we were looking for 2000 hours of uptime! We also moved onto using things like thread safe lists etc. within the script. I will have to give my code a try with 2.3 to see if it fails monumentally...:> Thanks for the hint though...will hopefully be able to do something along the same lines... the main difference I can see at first glance is that you lock and unlock, I assume the thread context and also restore the old one...I probably should have done that too...sloppy on my part.... I am trying to build a generic callback class (yeah c++) that I can use within modules as I have several uses for this functionality. Just a thought anyone played with Boost.Python? As that is another thing on my list... Anyway I know I am swamping the UK list, relatively...but it is far less to peruse than the main Python List which is drowning my mail box... -----Original Message----- From: python-uk-bounces@python.org [mailto:python-uk-bounces@python.org]On Behalf Of Duncan Grisby Sent: 15 August 2003 12:28 To: UK Python Users Subject: Re: [python-uk] Extending Python - Asynchronous Callbacks On Friday 15 August, "Phil Hornby" wrote:

Me and another guy have done some stuff with Asynchronos callbacks from another thread...took a bit of playing to get it to work...We had several instances of long uptimes but after, sometimes, 3 days you would have a clash...the joys of concurrency...

[...]

PyEval_RestoreThread(this->pPythonCBThreadState); // pretend that

we're

the callback python thread

That will break on debug versions of Python 2.3, since it asserts that a thread state always lives with the same thread. I wrote some code in omniORBpy that maintains a cache of thread states for callbacks, and copes with Python 2.3's new GIL access functions. You can see the code from SourceForge's CVS. Apologies for the ridiculously long URLs... http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/omniorb/omniORBpy/modules/Att ic/pyThreadCache.h?rev=1.1.2.2&only_with_tag=omnipy2_develop&content-type=te xt/vnd.viewcvs-markup http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/omniorb/omniORBpy/modules/Att ic/pyThreadCache.cc?rev=1.1.2.5&only_with_tag=omnipy2_develop&content-type=t ext/vnd.viewcvs-markup Cheers, Duncan. -- -- Duncan Grisby -- -- duncan@grisby.org -- -- http://www.grisby.org -- _______________________________________________ python-uk mailing list python-uk@python.org http://mail.python.org/mailman/listinfo/python-uk