<br><br>
<div><span class="gmail_quote">On 11/23/09, <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;Select (on inputs) requires single-receiver channels. Multiple senders are &gt;OK. Given that restriction, a select can be implemented without race &gt;conditions.<br>
<br>Okay I think I get what you are saying. If you are doing a receive(), having multiple senders is okay. And if you are doing a send(), having multiple receivers are okay. However if you are doing a receive, and there is another receiver beats you to the punch, that is a problem. With a little change to the select() interface, this could be detected and an exception could be raised.</blockquote>

<div> </div>
<div>Even better, you could have mutually exclusive species &quot;channel-with-multiple-receivers&quot; and &quot;channel-with-select&quot;. An attempt to initialize a select would fail if the channel has more than 1 receiver. An attempt to add another receiver would fail if the channel has a select underway. Better yet (in my personal opinion), the two kinds of channels would be distinguished at declaration.</div>

<div> </div>
<div>Larry</div>
<div> </div><br>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">Cheers,<br>Andrew<br><br><br><br></blockquote></div><br>