Christian Tismer :

I'd like to keep track of tasklets, since they are now containing vitual information about stack state, and I cannot afford to loose one of them, or we'll crash.

I'm not sure what the problem is here. A tasklet isn't going to go away until there are no more references to it anywhere, and once that happens, there is no longer any way of switching to it.

So my basic idea was to provide what is needed to get uthreads at very high speed, without the ned to use Python for the basic machinery.

Well, the higher-level stuff doesn't *have* to be implemented in Python. But I think it should in principle be possible. Then you can experiment with different designs for higher-level faciliies in Python, find out which ones are most useful, and re-code those in C later.

My tasklets will also support threading, that is they will become auto-scheduled if the user switches this on.

I'm not sure how this is going to interact with the facility for switching to a specific tasklet. Seems to me that, in the presence of pre-emptive scheduling, it no longer makes sense to do so, since some other tasklet could easily get scheduled a moment later. The most you can do is say "I don't want to run any more now, let some other tasklet have a go". So it appears that we already have two distinct layers of functionality here: a low-level, non-preemptive layer where we explicitly switch from one tasklet to another, and a higher-level, preemptive one where we let the scheduler take care of picking what to run next. These two layers should be clearly separated, with the higher one built strictly on the facilities provided by the lower one. In particular, there should be exactly one way of switching between tasklets, i.e. by calling t.transfer(). Preemptive switching should be done by some kind of signal or event handler which does this.

But auto-scheduled frames are a diffeent kind of thing than those which are in "waiting for data" state. I need to distinguish them or I will crash.

If you get rid of the idea of passing values between tasklets as part of the switching process, then this distinction disappears. I think that value-passing and tasklet-switching are orthogonal activities and would be better decoupled. Greg Ewing, Computer Science Dept, +--------------------------------------+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | greg@cosc.canterbury.ac.nz +--------------------------------------+

Greg Ewing 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 haven't thought enough about the "unamed produce-and-continue function" to decide how exactly it should 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 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? -- -Jas -------------------- www.maya.com Jeff Senn | / / |-/ \ / /|® Chief Technologist | /|/| |/ o | /-| Head of R&D | Taming Complexity®

Jeff Senn wrote:

Greg Ewing 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@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/

Greg Ewing wrote:

Christian Tismer :

...

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@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/

Gordon McMillan :

Unless you've got a way to detect or pass tasklet's through transfer, you don't have enough.

You'll have to elaborate. I don't have any idea what you mean by that! Greg Ewing, Computer Science Dept, +--------------------------------------+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | greg@cosc.canterbury.ac.nz +--------------------------------------+

Gordon McMillan :

You need a way to refer to "this" tasklet from Python

Yes, that occurred to me as well. Would a built-in function called current_tasklet() provide what you want? Greg Ewing, Computer Science Dept, +--------------------------------------+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | greg@cosc.canterbury.ac.nz +--------------------------------------+