| Guys
this is so great! Thanks for letting me copy your texts! I hope it's clear that being in that note doesn't mean that you necessarily support my views. I'll add a disclaimer about that.
In the copies I was tempted to emphasize some with a red vertical line - which has now been removed! That was plain wrong! Sorry!
It is interesting to see the golang-nuts and golang-dev communities compared to this group's knowledge. This is rock solid, the other is more or less believeing this and that. But the core people show up now and then. And some whi are active are really good, as well.
Shouldn't we make a new google group and move our discussions open in the future? Something with a modern name etc. No, I won't be the admin, it must be someone young! Young??
Øyvind I think Rick’s observation is very pertinent. In designing the Graphics Slave (now released, by the way — see https://www.kickstarter.com/projects/767046121/crawl-space-computing-with-connel/posts ), I had to deal with Windows’ “callback” approach to graphics events. This does nothing that a CSP-type channel approach cannot do, nor does it give quicker response (on the contrary — as the Linux XCB graphics shows), and callbacks are far more complicated, incomprehensible and error-prone. But it allows the pretense that communications are “non-blocking,” by hiding what Rick calls the “state progressions,” which of course are blocking.
Non-blocking in the sense of buffered output is more understandable, because it really does provide some extra utility, and it is NOT incomprehensible. By explicitly programming an ack, you can force it to behave in an “occam-like” fashion if you want. This is what I did in Connel, since all the common channel-analogues offered by modern OSs seem to be buffered.
Larry Hi,
The 'blocking' terminology issue seems to me also to be tied up with OS terminology. In particular, standard APIs exist for blocking I/O and for non-blocking I/O, which typically use (or avoid) mutex locks. In the non-blocking I/O case, the OS API provides some means of registering callbacks to deal with state progressions.
The same is very much true for the Java virtual machine also.
For this reason and for reasons others have mentioned, I feel that it is wrong to describe channels with this terminology because it evidently causes nuances and misunderstandings in those not very familiar with a CSP or Occam way of doing things. 'Waiting' on a channel communication is helpfully different.
As Roger mentioned, the terms synchronous and asynchronous are widely used outside of their original clocked vs unclocked meanings. Many people would describe a zero-buffer channel as "synchronous" but an infinite-place buffer channel as "asynchronous" because the sender never waits in the latter case. This terminology is flawed in my view; how do you differentiate between an infinite-buffer channel and a one-place buffer channel? The latter could behave "synchronously" or "asynchronously" depending on the current dynamic state; clearly, using synchronous and asynchronous in this way lacks rigour. Alas, it seems to be pervasive though.
Rick
|