[Stackless] Select() on channels?
arnarbi at gmail.com
Sat Sep 15 03:48:56 CEST 2007
On 9/15/07, Christian Tismer <tismer at stackless.com> wrote:
> > On 9/14/07, Richard Tew <richard.m.tew at gmail.com> wrote:
> > ...
> >> def alt_select(*channels):
> >> resultChannel = stackless.channel()
> >> # See if anything is already waiting, and if so return it.
> >> for c in channels:
> >> if c.balance > 0:
> >> return c.receive()
> > If the alt_select is inside a loop and there's always something
> > available on some channel, this will cause starvation of the channels
> > that come after that one in the list. The CSP model calls for
> > non-determinism here but with a condition that when multiple channels
> > have available data, you should give them all an equal probability of
> > being selected so in the long run they all get served.
> But I don't really understand Arnar's input right now.
> Can you please formulate it, again? What is it exactly
> what we're missing?
The typical use of this would be inside of some event processing loop.
Say you're writing a server and have 10 connected clients.. to process
the data the clients send you'd have a loop like this (greatly
simplified of course):
chans = <your list of channels, one for each client>
ch, data = alt_select(*chans)
<do your thing with data and respond to the client>
Now, the code I snipped out from Richard's post above begins each call
of alt_select by checking if there's a channel with data available
already and just picks the first one it finds. What if client number
0 is so fast to provide data that on each iteration of the loop it
gets selected? In that case all the other clients are starved. So in
order to make the alt_select function usable in the general case, it
must pick a "random" choice of the ready channels.
Sorry if that's not the point you were asking about :)
Hoare mentions this in the original CSP paper  and notes that in
practice the choice must be "fair" to all processes ready to receive
or output data. In his book however, he doesn't require this
"fairness" though when dealing with the theory (, page 84).
More information about the Stackless