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

[tismer Kaun]

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
requirements.
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
state.


cheers - stackless chris