共享内存与 Go 通道通信
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!
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(3)
当我读到这篇文章时,我首先想到的就是 Stackless Python。 Go 中的通道让我想起了很多 Stackless Python,但这可能是因为 (a) 我使用过它,以及 (b) 它们实际上带来的语言/思想来自我从未接触过。
我从未尝试过使用通道作为 IPC,但这可能是因为替代方案可能更安全。下面是一些伪代码:
program1program2
如果您使用传统的IPC
方法,则可以在每一侧都有通道,将其通信包装在其之上。这导致了实施中的一些问题,我什至无法考虑如何解决,并且可能会出现一些意想不到的竞争条件。
不过,我同意;使用与 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:
program1
program2
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.
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.
我已经考虑过做类似的事情来包装 MPI 库。我目前的想法是使用类似
where comm.Send 和 comm.Recv 包装 ac 通信库的东西。我不确定你如何为两个不同的程序设置频道,但我没有这方面的经验。
I've looked at doing a similar thing for wrapping the MPI library. My current thinking is to use something like
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.