<div>I&#39;m not sure I follow you here: the &quot;mechanism that waits for multiple inputs and selects one of them&quot; certainly does not look like a channel; it looks like a case statement.</div>
<div>&nbsp;</div>
<div>&quot;[I]f there is no consumer, should the first producer block?&quot; Yes: if consumers&nbsp;can be&nbsp;conditional, then producers have to be unconditional, otherwise deadlock is legal.&nbsp;&quot;What do other producers do after an input has been selected?&quot; 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.<br>
<br>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 &quot;Clear to send&quot;, 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&nbsp;with a one-byte input saying &quot;Let&#39;s go!&quot;.</div>

<div>&nbsp;</div>
<div>&quot;The naive solution was to have a tasklet wait on multiple channels. I ended up running into deadlock situations.&quot; An input-only fair&nbsp;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&#39;t work: you have to go to many-to-one (but I don&#39;t see that as a practical problem, because distribution to workers can be done by an array of one-to-one channels).</div>

<div>&nbsp;</div>
<div>Larry<br>&nbsp;</div>
<div><span class="gmail_quote">On 10/15/08, <b class="gmail_sendername">Andrew Francis</b> &lt;<a href="mailto:andrewfr_ice@yahoo.com">andrewfr_ice@yahoo.com</a>&gt; wrote:</span>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">Hi Larry:<br><br>&gt;Is this essentially different from setting up a many-to-one channel, i.e. &gt;a channel which it is illegal for a tasklet to use for input if it is &gt;already &quot;registered&quot; as being used for input by another tasklet?<br>
<br>I don&#39;t know about the illegal part.... And maybe my sketch is different in that I don&#39;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&#39;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?<br>
<br>What is really neat about Stackless Python is with channels, under the hood, it is easy to to prototype synchronization mechanisms.<br><br>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.<br>
<br>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.<br><br>Cheers,<br>
Andrew<br><br><br><br><br><br><br><br><br></blockquote></div><br>