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

[Christian Tismer]

Greg Ewing wrote:

> Christian Tismer <tismer at tismer.com>:


...

> I can see the attraction of having pre-emption built in this
> way -- it would indeed be extremely efficient.
> 
> But I think you need to make a decision about whether your
> tasklet model is going to be fundamentally pre-emptive or
> fundamentally non-pre-emptive, because, as I said before,
> the notion of switching to a specific tasklet is incompatible
> with pre-emptive scheduling.


Yes. I will go a bit further and adapt the process model
of the Alef language a bit.

> If you want to go with a fundamentally pre-emptive model,
> I would suggest the following primitives:


[blocking stuff  - ok]


> Using this model, a coroutine switch would be implemented
> using something like
> 
>    def transfer(t):
>       "Transfer from the currently running tasklet to t."
>       t.unblock()
>       current_tasklet().block()
> 
> although some locking may be needed in there somewhere.
> Have to think about that some more.
> 
> For sending values from one tasklet to another, I think
> I'd use an intermediate object to mediate the transfer,
> something like a channel in Occam:
> 
>    c = channel()
> 
>    # tasklet 1 does:
>    c.send(value)
> 
>    # tasklet 2 does:
>    value = c.receive()
> 
> Tasklet 1 blocks at the send() until tasklet 2 reaches
> the receive(), or vice versa if tasklet 2 reaches the
> receive() first. When they're both ready, the value is
> transferred and both tasklets are unblocked.
> 
> The advantage of this is that it's more symmetrical.
> Instead of one tasklet having to know about the
> other, they don't know about each other but they
> both know about the intermediate object.


Yes. This all sounds very familiar to me. In private
conversation with Russ Cox, Bell Labs, I learned
about rendevouz techniques which are quite similar.

Having read the Alef user guide which can be found at
http://plan9.bell-labs.com/who/rsc/thread.html
http://plan9.bell-labs.com/who/rsc/ug.pdf
I got the following picture:

(Thanks to Russ Cox, these are his ideas!)
We use a two-level structure. Toplevel is something
similar to threads, processes in Alef language.
These are pre-emptively scheduled by an internal
scheduler that switches after every n opcodes.
These threads are groups of tasklets, which have
collaborative scheduling between them.

This gives us a lot of flexibility: If people prefer
thread-like behavior, they can use the system
provided approach and just use the toplevel layer
with just one tasklet in it.
Creating new tasklets inside a process then has
coroutine-like behavior.
I'm just busy designing the necessary structures,
things should not get too complicated on the C level.

>>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.
>>
> 
> As I said before, if there are no references left to a
> tasklet, there's no way it can ever be switched to again,
> so its C stack is no longer relevant. Unless you can have
> return addresses from one C stack pointing into another,
> or something... can you?


Well, the problem is that an extension *might* be sitting
inside a tasklet's stack with a couple of allotted
objects. I would assume that the extension frees these
objects when I send an exception to the tasklet.
But without that, I cannot be sure if all resources
are freed.

thanks a lot for your help - 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