[Stackless] Stackless based replacement
ldickson at cuttedge.com
Wed Oct 15 16:39:35 CEST 2008
I'm not sure I follow you here: the "mechanism that waits for multiple
inputs and selects one of them" certainly does not look like a channel; it
looks like a case statement.
"[I]f there is no consumer, should the first producer block?" Yes: if
consumers can be conditional, then producers have to be unconditional,
otherwise deadlock is legal. "What do other producers do after an input has
been selected?" Channels have to wait for another branch or loop to select
them. This can lead to starvation unless fairness strategies are used.
Timers can be thrown away since the timer provides no data.
After working through this in the last few days, the central idea seems to
be that someone has to initiate data flow, and it may as well be the
producer. (In theory it could be the consumer setting a "Clear to send", but
making it the producer seems more intuitive.) That creates an assymmetry
between inputs and outputs (select on inputs, use many-output-to-one-input
funnels, etc) but does not exclude anything practical, since if you want to
select on an output, you just precede it with a one-byte input saying "Let's
"The naive solution was to have a tasklet wait on multiple channels. I ended
up running into deadlock situations." An input-only fair select mechanism at
the top of a loop has always worked flawlessly for me, even in heavy random
applications like RAID drivers using disks that respond differently (and
thus out of expected order). The design is trivial - I included it in one of
my files. The only thing is that many-to-many channels won't work: you have
to go to many-to-one (but I don't see that as a practical problem, because
distribution to workers can be done by an array of one-to-one channels).
On 10/15/08, Andrew Francis <andrewfr_ice at yahoo.com> wrote:
> Hi Larry:
> >Is this essentially different from setting up a many-to-one channel, i.e.
> >a channel which it is illegal for a tasklet to use for input if it is
> >already "registered" as being used for input by another tasklet?
> I don't know about the illegal part.... And maybe my sketch is different in
> that I don't directly use channels and I am silent on blocking. I guess one
> of my points is it is fairly easy to write a mechanism that waits for
> multiple inputs and selects one of them. I just don't feel there is a need
> to make the mechanism look like a channel. What is trickier (and more
> interesting) is determining behaviour - i.e., if there is no consumer,
> should the first producer block? What do other producers do after an input
> has been selected?
> What is really neat about Stackless Python is with channels, under the
> hood, it is easy to to prototype synchronization mechanisms.
> Another point - when I first started using Stackless Python - my first
> exercise was to use channels to impose logical orderings on the execution
> order of tasklets. The naive solution was to have a tasklet wait on multiple
> channels. I ended up running into deadlock situations.
> I got out of this by being more conscious of stuff like hold-and-wait
> conditions and simplifying design (mechanisms that use a single channel and
> counters). Channels are power but you have to be real careful.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Stackless