在探索 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]
这就是我对宏所做的。它使事情更容易跟踪少 1 个变量（在 100 个变量中）。尽管它远非“理想”，因为它要求宏位于相同的“功能范围”内，但这很容易解决。
虽然我的示例是 C，但这有点与语言无关。
因此，问题是，创建这样的上下文有什么意义/好处？
什么时候允许这样的功能实际上是不利的？因为我可以很容易地预见到很多（他们只是复制/粘贴/编辑代码），而不考虑额外的开销，并在不需要时创建“很多上下文”[对于其他类似的结构多次看到，尽管它们的存在已经自己的理由]
我这么说的原因之一是我正在考虑在初学者游戏编程模块中使用 zeroMQ。很大程度上是因为它的简单性，以及插座往往会为新人烧毁脑细胞这一事实。
随机，我实际上证明了谷歌 V8 上下文系统的基本原理（类似的问题；不同的系统）： HandleScope 背后的设计原理是什么？