如何使用 boost::beast 避免回调地狱？答案

【问题标题】：how to avoid callback hell with boost::beast?如何使用 boost::beast 避免回调地狱？
【发布时间】：2019-01-11 19:32:09
【问题描述】：

我正在开发一个我想在其中使用 boost::beast/asio 的应用程序。我需要通过 websocket 连接接收数据并同时向 REST API 发出请求。

在 boost::beast websocket/HTTP 异步客户端示例中，似乎下一个异步操作是在完成处理程序中启动的。这似乎引发了我在 node.js 应用程序中看到的相同的“回调地狱”。

为了避免这种情况，我正在考虑在我的应用程序中使用一个简单的状态机来决定接下来要开始什么操作。我正在考虑在我的应用程序中有一个 while 循环，我在 io_context 上调用 poll() 之后我运行我的状态机代码（例如 switch(state) { ... state = nextState; } ）

但是这可能会造成一个繁忙的循环，其中主线程在不断运行状态机的同时消耗 100% 的 cpu？

我的推理是否正确，使用 post() 之类的东西来排队一个可以推进状态机的函子会更好吗？

【问题讨论】：

标签： boost boost-asio boost-beast beast-websockets

【解决方案1】：

我希望我可以将此作为评论留下，因为它并不是一个完整的答案，但我没有足够的声誉来发表评论。

如果您谈论的是 node.js，我假设您对“promises”和/或更新的“async/await”有一定的经验 - 至少 node.js 是这样避免回调地狱的。

原来 Boost Asio 有一些类似于 node.js 'async/await' 的东西。它被称为 Boost Asio Coroutines，你实现它的方式与 node.js 'async/await' 完全相同。

不确定运行一个消耗 100% 线程的 while 循环是否是个好主意？当有更好的解决方案时，这有点浪费。

【讨论】：

感谢您的回复。我讨厌带有 promises 和 async await 的整个 node.js 方法。这非常令人困惑，我看不到自己用它构建任何体面的应用程序。状态机的优点是将逻辑集中在一个地方，这比将其分散在无数个回调中要好得多。我知道承诺可以被链接起来，但对我来说它并不能解决任何问题。它只是引入了一堆混淆实际发生的语法。
我不熟悉 javascript，但我喜欢 boost::asio 中的协程。它们的行为很像线程上的阻塞 IO，但开销要少得多。您的函数在执行调用时会暂停，直到返回结果，您不必提供回调。