Language agnostic zeroMQ上下文背后的基本原理是什么？

在闲逛时，我在邮件列表中遇到了这个问题：

使用多个上下文是否有缺点？我有一个类包装器，我希望尽可能简单。我可以修改它以允许在单个上下文下进行多个连接、套接字等，也可以保持原样，让包装器的客户端多次实例化它

在我看来有两个缺点

占用资源效果不佳（额外内存占用、另一个I/O线程等）

在不同上下文中创建的套接字无法使用“inproc”传输相互通信。“inproc”这个名字有点用词不当；它真正的意思是“内语境”

铬

回顾我的和其他各种源代码，我最终意识到上下文设置代码：

void *context = zmq_init (1); //creates the context 

void *responder = zmq_socket (context, ZMQ_REP); //creates the socket

zmq_bind (responder, "tcp://*:5555"); //and binds it

... //Do whatever you want with the socket ...

zmq_close (responder); //destructors
zmq_term (context);

可以有效地由以下内容取代：

void *context = zmq_init(1); //saving the context is optional

responder = zmq_socket(type); //creates the socket
//additional [context] can be provided if desired (multi-context?)

zmq_bind (responder, "tcp://*:5555"); //and binds it

... //Do whatever you want with the socket ...

zmqx_dest(); //destroys the global context, else provide alternative [context]

这就是我对宏所做的。在100个变量中，少跟踪1个变量会更容易。虽然它远不是“理想的”，因为它要求宏在相同的“功能范围”内，但这很容易解决

虽然我的例子是C，但这有点像语言不可知论

---

因此，问题是，创建这样的上下文有什么意义/好处？

什么时候允许这样的功能实际上是一个缺点？因为我可以很容易地预见到许多人（他们只是复制/粘贴/编辑代码），不考虑额外的开销，在不需要的时候创建“大量上下文”[对于其他类似的结构，我多次看到这一点，尽管他们的存在有其自身的理由]

我这么说的原因之一是，我正在考虑在初学者游戏编程模块中使用zeroMQ。很大程度上是因为它的简单性，以及插座倾向于为新来的人炸脑细胞这一事实

---

随机的，我实际上证明了谷歌V8上下文系统的基本原理（类似的问题；不同的系统）：

---

这是个好问题。如果你不需要保存全局上下文，为什么还要让应用程序创建它？libzmq可以在第一次需要时轻松地设置其状态

然而，0MQ较旧的API的问题并不在于它强制您使用上下文，因为上下文是套接字的自然父类。问题是，在努力创建和跟踪上下文之后，您的工作几乎没有任何价值。这似乎是全费无利

---

如果您查看最近的API，例如CZMQ和0MQ/3.1，您会发现上下文更有用。在CZMQ中，我们在销毁上下文时会完全关闭并销毁所有套接字。这真的很有用。在0MQ/3.1中，我们添加了一些上下文配置，例如I/O线程的数量等。此外，API与类模型（看起来也更像CZMQ）更加一致（zmq_ctx_new、zmq_ctx_set/get、zmq_ctx_destroy）。

因此，它可以简化为一个方便的容器，以便在需要时进行处理=D