[go-nuts] Re: elastic channel buffers

Hi,

What problems will it make easier to solve with Go?

kl. 04:58:18 UTC+1 mandag 13. januar 2014 skrev Dmitry Vyukov følgende:

Best question there is!

In the xchan paper's Appendix I have two Go examples (courtesy of
golang-nuts). However, answering this question I think the golang-nuts
group would be more qualified to do than I. I have mentioned xchan before
in this group, but not really suggested it as needed for Go. But then, in
the scope of this thread I thought it worth mentioning. Observe that the
two papers are peer reviewed under a rather rigorous regime (CPA).

The xchan paper also discusses the semantic differences between xchan and
(output) guards in select. Go does not have the boolean expression of
guards as first-class citizen, but it can simulate them and thus
effectively have a flavour of them. Therefore I infer that xchan in Go
would add something different. And with the introduction of 'feathering' in
the second paper the difference is even further emphasized. I am not
certain if feathering could be introduced if it were not for xchan.

One may view channels as the "goto of communication". In many use cases
they are used to build higher level patterns like f.ex. some kind of
transactions. If these patterns are then supported by the language which is
able to run 'usage checks' on them, then we see that chan is only the
beginning. The library provided for this thread addresses this, and also
contains an overflowing channel type, a comon way to try to make matters
safe. On the occam world we made oveflowing buffers to simulate this.

The 'xchan' is one such pattern. It joins asynchronous (buffered
non-blocking) and synchronous (blocking) thinking and practice. xchan
provides a 'safe' asynchronous mechanism on a synchronized foundation. I
have used several blog notes recently trying to understand the common view
that blocking is perceived as 'evil' and asynchronous is all that makes
sense. I think I have been able to explain. This view is so common that I
believe it is the main threat to Go, which easily may fail to tell that
blocking is not evil. Even in golang-nuts I see it often shine through that
chan needs to be buffered. I added buffering in xchan simply to avoid a red
cloth to most programmers, but it's not needed. I fail to see any system
where internal buffering + xchan with no buffering is not best.

The 'feathering' is also one such pattern - where explicit non-interest
saves us communications. It's an implicit type of subscription mechanism.

I have suggested at least one example of xchan use in the paper. A server
connected to an incoming connection, where the server never ever blocks
because it empties itself over an xchan. So the server is always able to
handle a connection. And overflow, flushing, prioritation atc. are handled
by the server *application*.

xchan could potentially also help moving Go into the safety-critical
(embedded) world, but I guess that is a far cry out.

Øyvind

Is it Section 5.2 Local ChanSched ANSI C with Channel-Ready-Channel?

kl. 10:42:17 UTC+1 mandag 13. januar 2014 skrev Dmitry Vyukov følgende:
Yes, but that example is tied to a small embedded system with "hand coded"
XCHAN and usage of it. The paper suggests a first-class citizen XCHAN, with
usage checks by the compiler (if possible). Mentioning xchan in this
golang-nuts thread would be a suggestion to try it out as a channel type in
package channels.

I may be missing something, but it seems to me that the use case is
already perfectly covered by non-blocking sends in Go:

for msg := range inchan {
   select {
   case outchan <- msg:
   default:
     // handle overflow (decide what value(s) to discard)
   }
}

Xchan looks like a neat concept, but I don't have the time/inclination to implement it myself at the moment.