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

[Christian Tismer]

Jeff Senn wrote:

> Greg Ewing <greg at cosc.canterbury.ac.nz> 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 tismer.com>
Mission Impossible 5oftware  :     Have a break! Take a ride on Python's
Kaunstr. 26                  :    *Starship* http://starship.python.net/
14163 Berlin                 :     PGP key -> http://wwwkeys.pgp.net/
PGP Fingerprint       E182 71C7 1A9D 66E9 9D15  D3CC D4D7 93E2 1FAE F6DF
      where do you want to jump today?   http://www.stackless.com/


_______________________________________________
Stackless mailing list
Stackless at www.tismer.com
http://www.tismer.com/mailman/listinfo/stackless