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

Question

在讨论zeroMQ(对于那些不知道的人来说是一个非常有用的套接字替换)时,我在邮件列表中遇到了这个问题:

使用多个上下文:使用多个上下文有不利之处吗？

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

我看到它有两个缺点.

1. 捆绑资源没有好的效果(额外的内存占用,另一个I/O线程等)
2. 在不同上下文中创建的套接字无法使用"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上下文系统的基本原理(类似的问题;不同的系统): 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).