<p>Yes, channels can allow for this, but as with locks directionality and ordering matter. Typically messages will only run in a particular direction. Nor will all channels be synchronous (they're a tool, not a panacea), they might be intermixed with infinite asynchronous queues as is commonplace at the moment. </p>

<div class="gmail_quote">On Feb 19, 2012 8:19 AM, "Sturla Molden" <<a href="mailto:sturla@molden.no">sturla@molden.no</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Den 18.02.2012 16:38, skrev Matt Joiner:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Recently (for some) the CSP style of channel has become quite popular<br>
in concurrency implementations. This kind of channel allows sends that<br>
do not complete until a receiver has actually taken the item. The<br>
existing ¬†queue.Queue would act like this if it didn't treat a queue<br>
size of 0 as infinite capacity.<br>
<br>
In particular, I find channels to have value when sending data between<br>
threads, where it doesn't make sense to proceed until some current<br>
item has been accepted.<br>
</blockquote>
<br>
That is the most common cause of deadlock in number crunching code using MPI.<br>
<br>
Process A sends message to Process B, waits for B to receive<br>
Process B sends message to Process A, waits for A to receive<br>
<br>
... and now we just wait ...<br>
<br>
I am really glad the queues on Python do not do this.<br>
<br>
Sturla<br>
<br>
<br>
<br>
<br>
<br>
<br>
______________________________<u></u>_________________<br>
Python-ideas mailing list<br>
<a href="mailto:Python-ideas@python.org" target="_blank">Python-ideas@python.org</a><br>
<a href="http://mail.python.org/mailman/listinfo/python-ideas" target="_blank">http://mail.python.org/<u></u>mailman/listinfo/python-ideas</a><br>
</blockquote></div>