[Stackless] More CSP

Christian Tismer tismer at stackless.com
Wed Jan 7 14:23:15 CET 2004

Hi Tom,


> Having started to dig around, I'm coming to the conclusion that I may
> start with an all-python solution that uses the existing channel support
> and various scheduling hooks.

Great to read this. It is exactly what I was going to suggest:
Try to build CSP basics on top of the existing stuff.
This will hopefully lead to more insight what is really needed,
what to change and enhance, and so on.

Note: Even the channels are not necessarily built-in, since
I simulated them, too, for my Zope demo.

> For example, par is very easy:
> (For the uninitiated, A par construct runs a bunch of processes in
> parallel, the par process itself terminates when all of the
> sub-processes have terminated).


Ok, PAR is in fact simple. One old question which might get
an answer in this process is: Should tasklets get some
extra features like reporting certain events automatically
via channels? Should that bechannels or simple callbacks?
Should tasklets be able to "return" to something like a "caller"?
Do we want features like broadcasting channels?
Well, let's see...

> -----------------------
> Comments:
> I'm assuming it's ok to send on a channel from multiple tasklets?? In
> occam this is a 'shared' channel, in JCSP an 'any-to-one' channel.

Yes, absolutely. At the moment, I have a problem if these
taklets are in different real threads, but that's another,
solvable issue.

> The use of a channel to signal tasklet-end is perhaps a bit heavy? Are
> chan.send() and chan.receive() the only ways to make the *current*
> tasklet block?

This is a principal question, of course.
At the moment, "real" blocking is only done via channels.
On the other ahnd, channels are absolutely cheap things.
At the moment, they cost a bit, since they always switch
stacks, but that's an iplementation detail. They will
be soft-switched, soon, and that's very very fast.

> Implementing alt entirely in python would probably get much more messy.
> In particular, it might require a new altChannel class, that looks like
> a channel (i.e. send/receive methods) but actually encapsulates more
> than one 'real' channel, or multiple underlying sends/receives per
> communication. This might be interesting as a proof of concept, but is
> not a long term solution.

Sure. I would appreciate a prototype, anyway. It is crucial
to find the "right" (meaning most effective) implementation
of "ALT". Especially, I'd like to get at the order of speed of
FreeBSD's kernel queues. Their primary trick is that they don't
rebuild a huge list of channels to be waited for on every call,
but they can reuse a given structure.
Given that we are waiting on events on N channels, and we got
answers on K channels, then computation time for the KEvent
approach is dependent from K, not N.

That means I'm not only aiming on a general ALT that creates
a new list all the time, but also something that re-uses a list
effecitvely. Makes sense?

cheers - chris
Christian Tismer             :^)   <mailto:tismer at stackless.com>
Mission Impossible 5oftware  :     Have a break! Take a ride on Python's
Johannes-Niemeyer-Weg 9a     :    *Starship* http://starship.python.net/
14109 Berlin                 :     PGP key -> http://wwwkeys.pgp.net/
work +49 30 89 09 53 34  home +49 30 802 86 56  mobile +49 173 24 18 776
PGP 0x57F3BF04       9064 F4E1 D754 C2FF 1619  305B C09C 5A3B 57F3 BF04
      whom do you want to sponsor today?   http://www.stackless.com/

Stackless mailing list
Stackless at stackless.com

More information about the Stackless mailing list