Co-routines

[Alan Kennedy]

thewrights at ozemail.com.au wrote:

> From the python grammar:
> 
>     funcdef    ::= "def" funcname "(" [parameter_list] ")" ":" suite
> 
> I want the statements in <suite> to be executed on a statement by
> statement basis, with no particular restrictions on *what* those
> statements are. It's the execution stepping I'm interested in...

Might your requirements be better met by a debugger, which is feeding
step instructions to a normal python program? This could be done
extending the Pdb debugger class in module Lib/pdb.py to implement
your own single step method. This could control various executing
suites of code, according to your chosen scheduling algorithm.

Or might you be better off to actually spawn separate threads, and
have each thread carry out each instruction, line by line, and then
enter a blocking wait for either a "continue" token from a
Queue.Queue(), or "Continue" message signalled on a
threading.Condition()?

> the I/O in my example was just that. 

Or is that you want to control the states of your objects, depending
on the readiness status of various I/O channels? And you want to run
everything in one thread? In which case you might be looking for
ultra-lightweight threads, based on generators, combined with an
asynchronous I/O detection and reaction platform, such as asyncore,
twisted or medusa.

> I understand that there will
> be all the problems on contention/race etc (just like if the
> functions were going in separate threads)

If the objects which are being distributed out to your
(ultra-lightweight) threads are local to the functions/objects (i.e.
not shared with other functions/objects) that process them, then there
is no contention, and thus no locking required.

How many separate "threads" of execution are you seeking to create?

-- 
alan kennedy
-----------------------------------------------------
check http headers here: http://xhaus.com/headers
email alan:              http://xhaus.com/mailto/alan