Ann: Stackless Limbo Dancing Works Fine!

[Christian Tismer]

Andrew Henshaw wrote:
> Christian Tismer wrote:
> ...snip...
> 
[snipped my description as well]

> Just so that I am clear -- in your concept of channels, can channels be 
> shared among multiple, parallel, sending processes?  What about multiple, 
> parallel, receiving processes?  In other words are your channels similar to 
> the Queue.Queue object?

a) yes, b) too, c) ...reading up Queue.Queue...
you meant Java's Queue class?
No, I don't implement almost any of the methods.
And I'm not queueing data, but proclets.
But yes, it is in fact a simple FIFO which
triggers reschedules as needed.

> The reason that I ask is that this is different from Occam's behavior (and 
> I believe CSP's).  In those systems, a channel should be assigned to at 
> most one concurrent sender and receiver.

At any time, there will be only one sender or receiver.
After one is done, another one may show up through
the queue.
Do you say a channel is only conected to at most
one sender and receiver in the sense of the whole
program? I believe so, since in Occam, channels
are denoted literally in the program text.

I didn't look at Occam in the first place, but
by reading about the Limbo language. There, a channel
is a first-class object, and it is explicitly
shared between processes which might want to communicate.
This is the reason that bade the implementation look
this way.

Anyway I'm not yet convinced if this was a good decision.
I have no education in parallelism and just followed
the hints of a couple of people at Bell Labs.

> If you need to merge the output 
> of multiple processes, then an ALT construct would be used to arbitrate 
> among the individual channels.  Under Occam, sending to the first available 
> receiver is more complex than in CSP, as it doesn't have ALT output guards 
> (difficult to implement on distributed processors, I believe); so, I'd 
> follow the CSP model here.

I'm trying hard to understand the CSP model at all,
reading articles, books, ...

> I suspect you already know all of this, but I thought I would mention it in 
> case there is some advantage to you in (conceivably) simplifying your 
> channel design.  You can still get the more complex behavior, but it would 
> be done explicitly.

I just tried to do the simplest possible while effective
thing. As said, I don't have the background to foresee
if the concept can stand a higher level of communication.

Does my attempt contradict CSP, and how? Then please
let me know. I also learned a few days ago that Occam
systems don't seem to use simple queues, but instead
pools of processes which are ready to send or receive
ofver certain channels. Appears to be quite more
complicated, using explicit scheduling decisions and so
on. I believe this is also necessary, because Occam
has to cope with real parallism, true channel I/O between
multiple processors or even machines and such.
My simple idea was based on the fact that I have one
CPU only, and even easier, it is always shielded by
the Python interpreter, the GIL, so I have complete
control over this simplified "hardware".

Please let me know. I don't want to fight for my idea,
but for the best solution in the context of Python.
We're talking about two pages of code, and I'm happy
to try out different approaches.

Thanks & cheers - chris

-- 
Christian Tismer             :^)   <mailto:tismer at tismer.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  pager +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/