[Stackless] Scheduling Examples, Problems, Solutions, and Questions

Joachim König-Baltes joachim.koenig-baltes at emesgarten.de
Fri Mar 24 09:39:27 CET 2006

Christian Tismer wrote:
> Channels were inspired by the idea of a minimal
> implementation and let people decide what they
> really need. Compatibility to existing stuff
> was never an issue for stackless. Extra things
> should be built on top of it.
> Having that said, even channels and the circular
> listof tasklets are premature design decisions
> whoch are overdone. At the time when I designed
> this I thought I would need it. After all, Stackless
> will be based upon very primitive coroutines, and
> the rest will be builton top of it.
Thanks for the explanation from the "father" of stackless.

I agree with your point of view that these things can
be build on top of it. I just wanted to understand the
differences to other approaches to get a better understanding
of the differences between [p]threads and tasklets concerning
communications between them.

> I have lots of examples of buffered channels, they
> can be implemented in different flavors, and you
> should not need more than few lines for this.
> So this is left as an excercise. Adding extra
> features is the best way to learn how things work.
Yes, of course, but it seemed so straightforward for me
that I was wondering if there might be a pitfall, thus
my question.

> They are not that often needed, and as Kristjan says,
> you will loose a valuable feature.
One nice feature is the queue of senders or receivers
which can be kept even with a buffer of a given size,
the other feature is the guarantied blocking until the
senders data has been consumed by the receiver which
can be achieved with a zero sized buffer. But as you
say, it can be easily implemented on top.

For that second feature, the guarantied delivery to the
receiver when the sender resumes, are there some easy
to understand examples that show the importance of
the feature? I do not question the value, I just want
to understand it in more depth.


Stackless mailing list
Stackless at stackless.com

More information about the Stackless mailing list