betreft:Re: [Stackless] Re: [Python-Dev] Stackless Design Q.

p.vrijlandt at p.vrijlandt at
Thu Feb 21 14:54:44 CET 2002

Hi all,

Could a timeslice function in C leave variables in python-code in any way 
I think statements in Python should probably be atomic (especially if one 
tasklet can get to variables in another)

Patrick Vrijlandt
---------- Tekst van het origineel ----------

Van: "Christian Tismer" <tismer at>, op 21-02-2002 14:48:
To: ISMTP at azninfo22@Servers["Jeff Senn" <senn at>]
ISMTP at azninfo22@Servers[<stackless at>];ISMTP at azninfo22@Servers[<python
-dev at>]

Jeff Senn wrote:

> Greg Ewing <greg at> writes:
>>It's not clear exactly what you're after here. Are you
>>trying to define the lowest-level interface upon which
>>everything else will be built? If so, I think what you
>>have presented is FAR too complex.
>>It seems to me you need only two things:
> ...
>>   t = tasklet(f)
>>   t.transfer()
> (Sorry if I missed something -- I've been *way* busy lately and
> haven't been giving this much attention -- that said...)
> But (if I understand the current plan) we will need mechanisms
> internal to the Python interpreter to transfer values and maintain
> blocked/running state anyway; since when you generate a tasklet and
> run it:
>  t = tasklet(f)
>  t.transfer()
> That may cause many more tasklets to be generated, run, and destroyed
> that you don't ever see ...  recursions/function calls in f, and
> only-Christian-knows what else...  so the transfer value mechanism
> might as well be built in.

I think all these little things are cheap to implement.

> I haven't thought enough about the "unamed produce-and-continue
> function" to decide how exactly it should work.

Somebody named it "resume", and together with "suspend" we get
a nice couple.
On the other hand: I'm not sure whether resume should block
its caller. I'm very undecided after all the input I got,
if it is in fact better to forget data transfer completely
by now and just make switching primitives which always work.

> I have two concerns in implementing uthreads this way (scheduler in
> C):
>  1 -- there doesn't seem to be anyway to "kill" a tasklet

Not yet, but I want to provide an exception to kill tasklets.
Also it will be prossible to just pick it off and drop it,
but I'm a little concerned about the C stack inside. This
might be the last resort if the exception doesn't work.

>  2 -- the scheduling algorithm will be hard to tune (we'll probably
>       *at least* need tasklet priority...)  Maybe there should still
>       be a "timeslice" function so an in-Python scheduler can be written?

We had the timeslice function, yes. I think to make things
simpler this time and just periodically call the scheduler
which is written in C. I also have a rough concept of
priorities which can be very cheaply implemented.
Maybe I implement some default behavior, but allow these
objects to be subclassed from Python?

ciao - chris

Christian Tismer             :^)   <mailto:tismer at>
Mission Impossible 5oftware  :     Have a break! Take a ride on Python's
Kaunstr. 26                  :    *Starship*
14163 Berlin                 :     PGP key ->
PGP Fingerprint       E182 71C7 1A9D 66E9 9D15  D3CC D4D7 93E2 1FAE F6DF
      where do you want to jump today?

Stackless mailing list
Stackless at

Stackless mailing list
Stackless at

More information about the Stackless mailing list