Question

在zeroMQ (A very useful socket replacement for those who don't know)进行搜索时，我在邮件列表中遇到了这个问题：

Using multiple contexts : Is there a downside to using multiple contexts?



使用多个上下文有不利之处吗？我有一个类包装器，我想尽可能简单。我可以修改它以允许在单个上下文下的多个连接，套接字等，或者保持原样并让包装器的客户端多次实例化它。



我看到它有两个缺点。


将资源捆绑到没有好的效果（额外的内存占用，另一个I / O线程等）

在不同的上下文中创建的套接字不能使用“inproc”传输进行相互通信。 'inproc'这个名字有点用词不当;它的确意味着“内部文化”。

CR

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

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上下文系统的基本原理（类似的问题;不同的系统）： What is the design rationale behind HandleScope?

Answer 1

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

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

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

zeroMQ上下文背后的理由是什么？

1 个答案: