<div>Hi Andrew,</div>
<div>&nbsp;</div>
<div>We seem to have different ideas of what is simple. You propose exceptions, waits, signals, barriers, re-initialization, and presumably global signal values. This in my opinion is a whole Italian restaurant of spaghetti, and it sounds intrinsically global, which is poison to maintainable multiprocessing in my experience. Of course I could be wrong, having little experience with your way of doing things, except for standard C/Linux signals. (Have you ever tried setting anything up with occam manager and workers?)</div>

<div>&nbsp;</div>
<div>The beauty of toplevel (stackless in the generic sense)&nbsp;processes communicating through channels is that they do not have to share resources OR KNOWLEDGE with other black boxes of the same construction but totally different function and/or history. This is what drivers try to be but never succeed. A manager based on&nbsp;ALT (or stackless_receive_first) can manage several of these black boxes - possibly of completely different types, like ethernet and disk - and apply optimal strategies to the data flow without digging deep into the driver code. But it has to be toplevel, not nested down deep like standard drivers.</div>

<div>&nbsp;</div>
<div>Larry<br>&nbsp;</div>
<div><span class="gmail_quote">On 10/16/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><br>--- On Wed, 10/15/08, Larry Dickson &lt;<a href="mailto:ldickson@cuttedge.com">ldickson@cuttedge.com</a>&gt; wrote:<br>
<br><br>&gt; I&#39;m not sure I follow you here: the &quot;mechanism that<br>&gt; waits for multiple inputs and selects one of them&quot; certainly does not<br>&gt; look like a channel; it looks like a case statement.<br>
<br>If I understand you correctly, I don&#39;t see a big difference (outside of less machinery) between<br><br>val = stackless.receive_first([chan1, chan2, ....])<br><br>and some construct, let us call it &#39;synchronizer&#39; (loosely based on the van Aalst workflow pattern - synchronizer). Usually synchronizers are synonymous with barrier synchronization.<br>
<br>val = synchronizer.wait(count) for N consumers, synchronizer.signal(some value) for the producers. In your case, you can wait for one.<br><br>chances are channels would be implemented under the hood....<br><br>If there is no consumer, a producer blocks. Once a synchronizer is triggered, future producers will raise an exception on a signal until the synchronizer is re-initialized.<br>
<br>Again, I just feel that channels are powerful. However my limited experience has been that scenarios where a single consumer waits on multiple channels can be replaced with a simpler construct that is far more controllable (and use few channels).<br>
<br>Cheers,<br>Andrew<br><br><br><br><br><br><br></blockquote></div><br>