Greg Ewing wrote:
> Christian Tismer <tismer@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@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/
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4