Ann: Stackless Limbo Dancing Works Fine!

[Christian Tismer]

Fernando Pereira wrote:
> On 5/17/02 9:30 PM, in article
> mailman.1021685435.8672.python-list at python.org, "Christian Tismer"
> <tismer at tismer.com> wrote:
> 
>>- There isn't yet an ALT/PRI ALT construct like in OCCAM/ALEF/LIMBO.
>>This is most sophisticated and very hard to implement correctly! I will
>>try to find out how to do this the best way, during my stay at IronPort,
>>from May 18th to May 29.
> 
> I was once involved in designing a channel facility with an ALT-equivalent,
> and I found the following paper very useful:
> 
> Luca Cardelli. An implementation model of rendezvous communication. S.D.
> Brookes, A.W. Roscoe and G. Winskel. Seminar on Concurrency, Carnegie-Mellon
> University, Pittsburgh, PA, July 1984. Lecture Notes in Computer Science,
> Vol. 197, Springer-Verlag, 1985, ISBN 3-540-15670-4. pp 449-457
> <http://research.microsoft.com/Users/luca/Papers/Rendezvous.pdf>

Thank you very much for this link. I started to read it
(but it is hard -- I'm deadly jet-lagged) and will try
to get my brain around it tomorrow.

At first glance, I'm a bit stunned. Did you see my channel
implementation? It is quite straight-forward and performs
fine. But the principles appear to be upside down from
those of the paper. My channels have a single queue of
waiting tasks, and this queue is either for reading or
writing.
Currently I have a hard time to understand why there can
be both an output and an input pool. My channels always
fulfil whatever is possible, so only one pool would
be populated at any time.
I think I did quite something similar to their rendevouz
operation.

Interesting is that they don't even take processes as
first-class objects. After introducin channels, I also
found my tasklets less useful than before, and maybe
they will survive only in a shadowy existance.

Anyway, what I didn't grasp really yet is how to
implement PAR as a multiple select on a group
of channels. Isn't this group of channels like
a special object, that will try to figure out a
ready channel with almost no computation time,
and continue the waiting process ASAP?
And if so, what happens afterwards? Is the
channel group thrown away? This looks quite
expensive. I'm expecting to wait on, say, 10000
channels over and over. This implies to create
such objects quite seldom and to re-use them as
long as possible, switching some off using guards.

Maybe I'm completely on the wrong track? I'd
really be interested to read about your
implementation. Anyway I hope to have a better
understanding of the article tomorrow when the
jet-lag has vanished a little.

thanks so much for your support, I really need to
learn more, soon!

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/