Aaron Watters wrote:
...
>> The "real time scheduler" doesn't work as well as it should.
>> I think the problem is that
>>>> task.run()
>>>> doesn't do what I expected -- I thought that when the task
>> blocked control would return to the task that called "run",
>> but it doesn't -- it goes to some other task. I think this
>> is wrong. schedule() can pick any task but run() should return
>> to the task that that invoked "run". ymmv.
I agree, and probably I intended to do so in the first place.
Then I changed my mind again.
The current meaning of run() is to
a) ensure that the task can run (or thow an exception if it's blocked)
b) rotate the executables chain so that it runs.
This doesn't guarantee anything about the caller's position.
First I thought to enforce it (and you may convince me to
do so), but then I realized that it *can* be enforced,
so I didn't need to do it always.
If you first remove() the task and then run() it, the task is
inserted right behind you. By yelling run(), you rotate
the executables to that one, and *you* are in place to be
run after that.
So I think the phrase
process.remove().run()
will do what you wanted. Please let me know if this is tedious
and should always be the default action of run().
ciao - chris
--
Christian Tismer :^) <mailto:tismer at tismer.com>
Mission Impossible 5oftware : Have a break! Take a ride on Python's
Johannes-Niemeyer-Weg 9a : *Starship* http://starship.python.net/
14109 Berlin : PGP key -> http://wwwkeys.pgp.net/
work +49 30 89 09 53 34 home +49 30 802 86 56 pager +49 173 24 18 776
PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04
whom do you want to sponsor today? http://www.stackless.com/
_______________________________________________
Stackless mailing list
Stackless at www.tismer.comhttp://www.tismer.com/mailman/listinfo/stackless