IPC between GO and C++ processes

[Senthil Murugan]

Hi All,

Is Inter process communication is available between GO and C++ .If so how can i achieve that and what are the ways to communicate between GO and C++.

Regards,
Senthil.

[Ian Lance Taylor]

On Thu, Jun 18, 2015 at 6:30 AM, Senthil Murugan <a.gau...@gmail.com> wrote:
>
> Is Inter process communication is available between GO and C++ .If so how
> can i achieve that and what are the ways to communicate between GO and C++.

What kind of inter-process communication do you mean? When I think of
IPC I usually think of pipes and Unix domain sockets. Both are
available in Go, much as they are in C++.

Ian

[Senthil Murugan]

I have to communicate GO process with C++ process . Using pipes can we communicate between C++ and GO ?.

[Konstantin Khomoutov]

On Thu, 18 Jun 2015 22:16:46 +0530

Senthil Murugan <a.gau...@gmail.com> wrote:

> > > Is Inter process communication is available between GO and C+
> > > + .If so how can i achieve that and what are the ways to
> > > communicate between GO and
> > C++.
> >
> > What kind of inter-process communication do you mean? When I think
> > of IPC I usually think of pipes and Unix domain sockets. Both are
> > available in Go, much as they are in C++.
> >

> I have to communicate GO process with C++ process . Using pipes can we
> communicate between C++ and GO ?.

Yes.

But be sure to start not with IPC but rather with a more general model.

Are your Go and C++ processes truly separate -- that is, started by
different means at possibly different times? If yes, they ought to
"find" each other using some rendez-vous point. And hence you'll need
to use sockets because the address of a socket is such a rendez-vous
point. And then one of the processes ought to listen on such a socket,
and another one should connect to it.

On the other hand, if these processes are coupled much more closely,
it makes sense to start one process by the other (say, your C++ program
runs your Go program or vice-versa). In that case, pipes are a way to
go, and most typically you'd use the standard streams of the called
process for communication: that is, the called process just writes data
to its standard output and reads it from it standard input.

In either case you have to understand that all IPC mechanism outlined
above deals with abstract (opaque) streams of bytes. This means, they
do not have any built-in notion of "a message", and you'll need to
implement a higher-level protocol over that IPC mechanism. It might be
as simple as some hand-rolled simple TLV-style protocol or something
already existing like Google Protocol Buffers, zero MQ etc.
You might find [1] interesting as it implements this approach.

You might also need no complicated messaging solution at all if the
called process is used for some one-off action and then quits.
In such case the calling process might just dump its request to the
called process's stdin in any format understood by the called process
and then close its end of the stream to signalize the called process
it's the end of the request so it has to process it, dump its response
to its stdout, flush it and quit. IOW, in this case message boundaries
are defined by termination of data streams, and hence the messaging
does not require any "framing" and so the messages themselves can be in
any format at all.

1. https://groups.google.com/d/topic/golang-nuts/lfb08InWrXU/discussion