[Stackless] Re: [Python-Dev] Stackless Design Q.
tismer at tismer.com
Fri Feb 22 09:15:19 CET 2002
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."
> 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:
> # 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
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
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
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
More information about the Stackless