用于 nim 的异步 ZeroMQ答案

【问题标题】：Async ZeroMQ for nim用于 nim 的异步 ZeroMQ
【发布时间】：2022-01-21 02:36:51
【问题描述】：

我从未使用过 ZeroMQ，并且在一小时前第一次听说它。但从指南 (this guide) 看来，似乎有异步 I/O。

也恰好有一个 nim 端口：this one

所以我想知道，异步魔法是否与async/await 有关，它们是 nim 端口（只是 c2nim）中不存在的关键字。那么它只是 ZMQ 内部的东西，API 不必为此烦恼吗？

我认为 async/await 是一个普通的东西，它必须冒泡到最上面的主循环（框架循环），所以 API 必须是异步感知的。

这完全是我的误解吗？

【问题讨论】：

标签： asynchronous zeromq nim-lang

【解决方案1】：

Native ZeroMQ API 支持阻塞和非阻塞 I/O。

为此，有flags，可以在其中添加zmq.NOBLOCK，从而实现非阻塞的运行方式。

各自的语言包装功能决定 . . .

如果我阅读了您上面提到的nim ZeroMQ-wrapper，在我看来，send() 和 recv() 函数包装器都有一个硬编码的阻塞版本。

包装器似乎也不支持正确的有线消息大小，以防 distributed-system 的基于 nim 的节点遇到另一个使用 ZeroMQ 版本 2.1.+ 的节点，这在异构 @ 中仍然很有趣和常见987654325@领域。

ZeroMQ 还有一个poll() 方法，配备了timeout 参数，这样您的多路I/O 操作可能会产生在一些软实时下如何操作多个I/O 通道的所有想要的方法控制约束。

【讨论】：

也许使用 ZMQ 的异步 API 需要确保缓冲区是固定的（因为 nim 是垃圾收集的），这使得它不是微不足道的？不知道。
在使用 ZeroMQ 十多年后，我猜想，在不久的将来对 Context()-instance 内存管理进行重新设计并不容易，因为已经花费了很多性能调整[man*years] 精英设计和工程努力（以及导入的 DLL 组件恕我直言，与以端口为目标的生态系统 (nim) 垃圾收集器或其他功能无关，它们位于 API 介导的 DLL-ed 的“前面”子系统）。因此，如果 nim-port 提供未失真的 API 服务，但它只能重用外部的、DLL 导入的功能。如果没有，则没有任何功能
据我所知，我绝不是 zmq 专家（但我确实在 Nim 中编写了异步等待），您需要以某种方式将 zmq 与 Nim 的事件循环集成。前面提到的poll 听起来像是一个好的开始，尽管在此过程中存在不少挑战。如果您需要一些帮助以使其正常工作，请随时在 IRC 上与我联系 :)
@v.oddou 问候东京，猜猜你不会错过 Dominik 在此评论上方的报价。

【解决方案2】：

虽然当时接受的答案是正确的；现在使用包装器构建与 ZMQ 的异步，并提供了示例：

见：

您还可以解决阻塞行为或 ZMQ，以便不使用 poll / sleepAsync 手动阻塞异步调度循环：

let
  zmq_timeout = 50
  async_loop_time = 450 # spend more time on async stuff than on zmq stuff
var
  conn = listen("tcp://127.0.0.1:36000", mode = PAIR=
  poller = initZPoll([conn], ZMQ_POLLIN)

if poller.poll(timeout):
  if events(poller[0]):
    var res = poller[0].receive()
    # Do async stuff
else:
  waitFor sleepAsync(async_loop_time) # Calling sleepAsync is a trick to make the async dispatch loop progress for a time

【讨论】：