Re: inter-process communication through channels

[Larry Clapp]

On Wednesday, September 26, 2012 4:30:17 AM UTC-4, xavier...@gmail.com wrote:

Go implements coroutines for communicating between two threads. Dart implements this need by isolates... But Isolates are also able to perform communication between two processes according to the VM implementation choice.
What if Go would implements a method to perform this communication through theads or processus via an unified channel? Netchannels could be used but it is to heavy for communication on the same machine.
What is the idiomatic way to do this in Go?

I can't speak for anyone else, but I "stalled" on a couple parts of this question.

• I'm not sure what you mean by "Go implements coroutines for communicating between two threads."  I would say, Go has something similar to coroutines called goroutines, which the runtime can automatically switch between threads, and which normally communicate with each other using channels, basically a threadsafe FIFO, though they can also use shared memory more directly.
  
• I don't know Dart, and don't know what an Isolate is, or what a netchannel is.

Your question appears to be:

Dart uses the same mechanism to communicate between threads in the same process, and between different processes.  What's the best way to do that in Go?

Do I have that more-or-less right?

If so, I'd hazard a guess that a good way (dunno about the best way) is through net/rpc using JSON or gobs.  I bet with just a little work you could wrap a channel around that.  (Or maybe net/rpc does that already, I haven't played with it.)

But ... would you really want to?  It seems to me that there are a lot more things that can go wrong with networked RPC than with a regular channel between two threads.  Trying to use the same abstraction around two very different transport mechanisms seems fraught with peril.  (I think I read an essay by someone at Microsoft about this when they made networked file systems look like local file systems.  Suddenly a simple file copy was actually a network transfer, with all the issues of dns, network timeouts, and so on that came with it, but the "file copy" code wasn't really built to handle any of that.  This is what makes me think that channels-over-RPC might be a bad idea.)

But I might just not understand your question, and could certainly be wrong, regardless.  :)  But I thought I'd take a stab at it.

-- Larry

[Kyle Lemons]

Bingo.

There used to be a "netchan" package that could connect channels over a network, but channel send and recieve don't have convenent ways to get errors in-band.  You're much better off using a standard IPC mechanism like RPC or roll your own simple communication channel on tcp/udp/unix sockets or fifo/pipes (it's trivial in Go).

 

But I might just not understand your question, and could certainly be wrong, regardless.  :)  But I thought I'd take a stab at it.

-- Larry

--
 
 

[Jeff Mitchell]

> There used to be a "netchan" package that could connect channels over a
> network, but channel send and recieve don't have convenent ways to get
> errors in-band. You're much better off using a standard IPC mechanism like
> RPC or roll your own simple communication channel on tcp/udp/unix sockets or
> fifo/pipes (it's trivial in Go).

I've used the Go ZeroMQ package in the past. I didn't have any
problems with it, and ZeroMQ provides a flexible, message-oriented and
fast way to do interprocess communication (which can use native UNIX
sockets on supporting platforms).

You can easily integrate this with channels and goroutines to your liking.

--Jeff

[Xavier Mehaut]

Thanks for the answer ; what i would like is simply shared memory communication between processed like the one done between threads, eg 
http://www.cs.cf.ac.uk/Dave/C/node27.html

Regards

Xavier
Envoyé de mon iPhone

[si guy]

I still use netchan and you're right Kyle, errors can't be handled in band so I handle them out of band and in a very lazy configuration. The plus side is that the code that interacts with the channel doesn't really need to know that it is a network transfer ( I just have to make sure round trips aren't time sensitive). The down side is that request-response chan doesn't work. This is a low bandwidth application with a very complex set of messages and not having to handle the encoding and decoding saves a lot of work.