Shared memory vs. Go channel communication

Question

One of Go's slogans is Do not communicate by sharing memory; instead, share memory by communicating.

I am wondering whether Go allows two different Go-compiled binaries running on the same machine to communicate with one another (i.e. client-server), and how fast that would be in comparison to boost::interprocess in C++? All the examples I've seen so far only illustrate communication between same-program routines.

A simple Go example (with separate client and sever code) would be much appreciated!

Answer 1

One of the first things I thought of when I read this was Stackless Python. The channels in Go remind me a lot of Stackless Python, but that's likely because (a) I've used it and (b) the language/thoughts that they actually came from I've never touched.

I've never attempted to use channels as IPC, but that's probably because the alternative is likely much safer. Here's some psuedocode:

program1

chan = channel()
ipc = IPCManager(chan, None)
send_to_other_app(ipc.underlying_method)

chan.send("Ahoy!")

program2

chan = channel()
recv_from_other_app(underlying_method)
ipc = IPCManager(chan, underlying_method)

ahoy = chan.recv()

If you use a traditional IPC method, you can have channels at each side that wrap their communication on top of it. This leads to some issues in implementation, which I can't even think about how to tackle, and likely a few unexpected race conditions.

However, I agree; the ability to communicate via processes using the same flexibility of Go channels would be phenomenal (but I fear unstable).

Wrapping a simple socket with channels on each side gets you almost all of the benefits, however.

Answer 2

I've looked at doing a similar thing for wrapping the MPI library. My current thinking is to use something like

func SendHandler(comm Comm){
    // Look for sends to a process
    for {
     i := <-comm.To;
     comm.Send(i,dest); 
    }
}
func ReceiveHandler(comm Comm){
    // Look for recieves from a process
    // Ping the handler to read out
    for {
     _ = <-comm.From;
     i := comm.Recv(source);
     comm.From <- i;
     }
}

where comm.Send and comm.Recv wrap a c communications library. I'm not sure how you do the setting up of a channel for two different programs though, I've no experience in that sort of thing.

Answer 3

Rob has said that they are thinking a lot about how to make channels work as a (network) transparent RPC, this doesn't work at the moment, but obviously this is something they want to take the time to get it right.

In the meantime you can use the gob package which, while not a perfect and seamless solution, works quite well already.