[python-uk] Extending Python - Asynchronous Callbacks

Phil Hornby phil.hornby at accutest.co.uk
Fri Aug 15 13:59:54 EDT 2003

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

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 at python.org
[mailto:python-uk-bounces at 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
> 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...





 -- Duncan Grisby         --
  -- duncan at grisby.org     --
   -- http://www.grisby.org --

python-uk mailing list
python-uk at python.org

More information about the python-uk mailing list