Blocking is probably used because a read or write will do exactly that in a one to one straight up communication. Though used in an alt blocking might not aptly describe the state as only communications that are ready (i.e., will _not_ block) will be considered.
I dislike yield because yield gives the idea that you can back off from a blocking read or write call which you cannot.
On Sep 26, 2014, at 2:19, "Roger Shepherd" <rog@xxxxxxxx
I donât know the answer to you question.
I canât say that I like âblockâ - but it usage is certainly old and is common for multitask systems where the ability to create an extra task/thread/whatever to do communication is considered to be advantageous - hence ânon-blocking communicationâ.
I donât like âyieldâ either as this has a meaning along the lines of "to give place or precedence (usually followed by to): to yield to another; Will the senator from New York yield?â (from dictionary.com
) and it is not necessarily the case the case that there is anything else to yield to.
I prefer âwaitâ.
On the subject of language, I think the term âsynchronousâ is plain wrong when used to describe (occam) channel communication. The processes are âsynchronisedâ by the communication; the communication is âasynchronousâ - there is no clock which causes the communication to happen.
When was the phrase âblocking on a channelâ introduced and by whom? Hoare does not use it in his 1985 book. Roscoe almost does not use it, or I would say, he does not use it at all in this context in his version of the book thatâs PDFed. If this group does not know this, none will.
I am suggesting using âto yield on a channelâ rather than âto block on a channelâ. I have a blog note about it  and there is a discussion thread on golang-nuts . I include the figure here (and the intro text in golang-nuts):
Readers of golang-nuts know that âblocking is fine in Goâ. But often, when I talk with other programmers I would hear that âblocking is evilâ. I suggest that we go over to saying that âyielding on a channel is fineâ. Iâll explain:
The literate meaning of blocking is about something we donât want. It means I want to go somewhere but am stopped or delayed so I arrive too late. Or a door is blocked, in which case we must unblock it, hopefully without a bulldozer. Since this semantics outnumbers the people who understand CSP-based channel semantics we have an explanation problem.
With an explanation problem follows a mission problem.
Tell a basically single-thread programmer in C++ that blocking is good and you ask for much. His attention to try to understand something rather new, even if heâs used to linux select. Because often the code that does this linux select also does other rather independent matters. And itâs in his spec that these other matters also need to complete. And when you block on one matter itâs easy to see blocking as something evil. Because he or she is right in their own mind.
So which âblockingâ do you mean? 1. âBlocking on a channelâ or some shared resource controlled by a non-blocking algorithm. I believe these may be in the same group, ref. the Wikipedia page about Non-blocking algorithm 2. âBlockingâ away other required functionality 3. âBlockingâ as in deadlock, where the system cannot proceed, where there is a cycle in the dependency tree We already have good words for 2. = blocking as is, and 3 = deadlock. But we reuse blocking for 1.) which is not optimal. As said, I suggest 1. = yielding. This is an implicit yield that the application doesnât have control of. Not the explicit yield that some operating systems would supply in the API. The channel semantics as implemented in the scheduler does it for us.
What do you think of this? If we start to write âto yield on a channelâ or âyielding on a channelâ it could slowly creep into our language. And the C/C++ (and even Scala or Erlang) people would give us an ear. Especially if we agree with them that blocking is evil.
(I alse dare take comments on the idea.. Here, there or there)
Med vennlig hilsen / Best regards
Senior utviklingsingeniÃr, siv.ing. / Senior Development Engineer, M.Sc.
Autronica Fire and Security AS
Research and Development
UTC Building and Industrial Systems
Phone: +47 735 824 68
www.teigfam.net/oyvind/home/ (Also work-related)