[python-uk] Extending Python - Asynchronous Callbacks

[Phil Hornby]

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 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
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 at grisby.org     --
   -- http://www.grisby.org --

_______________________________________________
python-uk mailing list
python-uk at python.org
http://mail.python.org/mailman/listinfo/python-uk