Micro-Threads: uthreadsleep.py -- scheduling of uthreads to continue processing after given seconds
tismer at tismer.com
Wed May 24 03:02:45 CEST 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
> 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