Sirs
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 [1] and there is a discussion thread on golang-nuts [2]. 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)
[1] -
http://www.teigfam.net/oyvind/home/technology/092-not-so-blocking-after-all/
[2] -
https://groups.google.com/forum/#!topic/golang-nuts/OSBU8wjlES8
Med vennlig hilsen / Best regards
Øyvind Teig
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
E-mail: oyvind.teig@xxxxxxxxxxxxxxxx
www.autronicafire.no
www.teigfam.net/oyvind/home/
(Also work-related)