Boost::Beast非阻塞读Websockets？

Question

我们有一个完全同步的应用程序，而且永远是同步的，因为它基本上是一个命令行解释器，向我们的硬件发送低级命令，你不能同时有两个命令到硬件上。对于这种配置，我将只有一个客户端套接字以同步方式操作，一个命令发送到服务器，它与硬件对话，并将值发送回客户端，但就我目前所见，async_read是执行非阻塞读取的唯一方法。

通过Beast获得非阻塞读/写的最佳方式是什么？例如，在Windows中的TCP和Serial中，您可以窥视缓冲区以查看数据是否准备好访问，如果有，您可以发出读取命令，知道它不会阻塞，因为数据在那里。我不确定我是否只是在Beast中错过了这个功能，尽管我会说如果可能的话，拥有这样的功能会很好。

总之，基于这个，我有一个问题

首先，我能否以协程为例，不使用yield，而是创建并传递一个read_handler函数？

我采用了协程示例，并将这些函数构建到我的类中，并使用了与此线程答案完全相同的read_handler。How to pass read handler to async_read for Beast websocket?

它会像他所说的那样编译，但在接收到数据时不会触发设置断点。

我真的不需要像异步示例那样的完整的异步功能，将它推入不同的线程，事实上，这让我的生活变得更加困难，因为应用程序的其余部分不是异步的。因为我们允许来自不同来源(键盘/TCP/串行/文件)的输入，所以我们不能阻止等待数据。

Answer 1

通过Beast获得非阻塞读/写的最佳方式是什么？

由于websocket流的实现方式，不可能支持非阻塞套接字模式。

我是否可以以协程为例，创建并传递一个read_handler函数，而不是使用

？

如果您想使用完成处理程序，我建议您从一个异步示例开始，而不是从协程示例开始，因为这些示例已经编写为使用完成处理程序。

Answer 2

协程具有阻塞语义，而完成处理程序没有。如果您尝试使用协程示例，并使用完成处理程序替换will表达式，则对初始化函数的调用将不会像使用协程时那样阻塞。而且你不应该使用spawn。您说协程示例要简单得多，这可能是因为它类似于同步代码。如果你想让编写和理解变得容易，那么你必须使用协程。使用完成处理程序的代码将表现出通常与回调相关的“控制反转”。这是它们的工作方式所固有的，而不是您可以通过从使用协程的代码开始并更改完成令牌来更改的。