英文:
Shared memory vs. Go channel communication
问题
Go的一个口号是不要通过共享内存来通信,而是通过通信来共享内存。
我想知道Go是否允许在同一台机器上运行的两个不同的Go编译二进制文件进行通信(即客户端-服务器),以及与C++中的boost::interprocess相比,通信速度如何?到目前为止,我看到的所有示例都只是演示了同一程序例程之间的通信。
非常感谢提供一个简单的Go示例(包含独立的客户端和服务器代码)!
英文:
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!
答案1
得分: 7
当我读到这个问题时,我首先想到的是Stackless Python。Go语言中的通道让我非常想起Stackless Python,但这可能是因为我用过它,而且它们实际上来自的语言/思想我从未接触过。
我从未尝试过将通道用作进程间通信,但这可能是因为替代方法可能更安全。以下是一些伪代码:
程序1
chan = channel()
ipc = IPCManager(chan, None)
send_to_other_app(ipc.underlying_method)
chan.send("Ahoy!")
程序2
chan = channel()
recv_from_other_app(underlying_method)
ipc = IPCManager(chan, underlying_method)
ahoy = chan.recv()
如果您使用传统的进程间通信方法,可以在每一侧都有一个通道,将它们的通信包装在其上。这会导致一些实现上的问题,我甚至无法考虑如何解决,可能还会出现一些意外的竞态条件。
然而,我同意;使用与Go通道相同的灵活性通过进程进行通信将是非常棒的(但我担心不稳定)。
在每一侧使用通道包装一个简单的套接字几乎可以获得所有的好处。
英文:
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:
<h3>program1</h3>
chan = channel()
ipc = IPCManager(chan, None)
send_to_other_app(ipc.underlying_method)
chan.send("Ahoy!")
<h3>program2</h3>
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.
答案2
得分: 3
Rob说他们正在思考如何使通道作为一个透明的RPC(远程过程调用)工作,目前这还不起作用,但显然他们想花时间来做到正确。
与此同时,你可以使用gob包,虽然不是一个完美和无缝的解决方案,但已经工作得相当不错了。
英文:
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.
答案3
得分: 2
我已经考虑过为MPI库编写类似的封装。我目前的想法是使用类似以下的代码:
func SendHandler(comm Comm){
// 寻找发送到某个进程的消息
for {
i := <-comm.To;
comm.Send(i, dest);
}
}
func ReceiveHandler(comm Comm){
// 寻找从某个进程接收的消息
// 通过发送信号来读取
for {
_ = <-comm.From;
i := comm.Recv(source);
comm.From <- i;
}
}
其中comm.Send
和comm.Recv
封装了一个C通信库。但是我不确定如何为两个不同的程序设置通道,我对这方面没有经验。
英文:
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.
通过集体智慧和协作来改善编程学习和解决问题的方式。致力于成为全球开发者共同参与的知识库,让每个人都能够通过互相帮助和分享经验来进步。
评论