Micro-Threads: uthreadsleep.py -- scheduling of uthreads to continue processing after given seconds

tismer Kaun tismer at tismer.com
Tue May 23 21:02:45 EDT 2000

Howdy Mike, glad that you are in the club :-))

Mike Fletcher wrote:
> While playing with making a uthreads-based server, I have found the lack of
> a real-world-time sleeping function somewhat disconcerting (relying on
> number of time slices when the system could vary from a cycle per
> millisecond through a cycle every 10 seconds (on very heavily loaded
> simulations) isn't very useful).

I was waiting for such input.
Modifying the uthread kernel to support
real-time-slices as well is on my task list.
The necessary action is rather simple: let a
real-time event initiate a task switch, instead
of an artificial counter in the interpreter.

Alas, both make sense, so this will become yet
another funtion in continuationmodule.

> Accordingly, I created a module which provides for "sleeping" uthreads.
> Unfortunately, because you cannot properly "suspend" a uthread (i.e. declare
> that it is inactive until time x), there is no noticeable processor load
> reduction when you have only waiting threads :( .  This is a demo, not a
> production piece of code.  It is released into the public domain for
> whatever it's worth.

There is already a couple of enhanced uthread modules. Just v. Rosssum
did quite a lot of work in order to make his own variant of this, and
parts are probable to make it back into Will Ware's original module.

> To do processor load reduction, you would likely need to have a far more
> involved run mechanism.  It should be possible to do something such as, on
> the first cycle where there is no non-waiting thread, use time.sleep() to
> wait until the first waiting thread should be restarted.  This would seem to
> work with the current micro-threads philosophy (i.e. a single python thread
> running all the micro-threads), as you would be able to declare that there
> is no further work to do in the python thread until the timer wakes up.  In
> a multi-threaded scenario, that could not be guaranteed (unless you force
> the issue by preventing threads from adding to other thread's micro-thread
> collection)?  The ability to use almost no processing power when not active
> is somewhat of a requirement for many systems.

Just's version is already capable to cope with a bunch of real threads,
each one of these running any number of µthreads. Getting this timer
stuff right appears to be a task for myself. Please help me with the
proper design.

> Incidentally, continuations/uthreads is, without a doubt, one of the coolest
> things in Pythonica :) .  One question, why does the micro-threads library
> use non-thread-safe mechanisms (global lists etc.)?  It limits the use of
> the micro-threads to a single python thread.

I will send you the latest Just-uthread which is far beyond your
It will be published soon, together with Stackless 1.2.
Unfrtunately time doesn't permit to do this before Py 1.6 has left alpha

cheers - stackless chris

More information about the Python-list mailing list