c++在 async_receive 处理程序中增强 asio 同步写入
最初，我问 - 是否可以在套接字的 async_receive() 处理程序中执行 boost::asio::write() ？这是在单个线程中的单个 io_service 上发生的。我编写了一些代码来执行此操作，我认为它挂在 write() 调用上。但我忘记按游戏上的播放按钮（这是一个小型客户端服务器游戏）！但这不太符合我对 boost asio 的理解，所以我将保留这个问题，但要问，为什么这有效？
起初，我认为这是不可能完成的，因为线程无法处理 write() 调用，因为 io_service 已经忙于这个 asynch_receive() 作业。我认为我需要另一个线程执行 io_service.run()，该线程可以处理 write()。显然，事实并非如此。
我记得，一个线程只会一次执行一个 io_service 中的作业。如果是这种情况，并且我的应用程序正在运行，那么一旦您开始执行异步处理程序，您的作业就已经从队列中移出。正确的？
Originally, I was asking - is it possible to execute boost::asio::write() within a socket's async_receive() handler? This is happening on a single io_service, in a single thread. I have some code that's written to do this, and I thought it was hanging on the write() call. But I forgot to press the play button on my game (this is for a little client-server game)! But this doesn't quite fit with my understanding of boost asio, so I'll leave the question up, but asking, why does this work?
At first, I thought this couldn't be done, because the thread cannot handle the write() call since the io_service is already busy with this asynch_receive() job. I thought I would need another thread executing io_service.run(), that one could handle the write(). Apparently, that's not the case.
As I remember it, a thread will only execute jobs in an io_service one-at-a-time. If that's the case, and my app is working, then it must be that once you've begun executing the async handler, your job is already moved out of the queue. Right?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
考虑一下 Boost 使用特定于操作系统的 API 调用的底层 I/O 操作：套接字、串行通信或任何其他。没有任何事情可以阻止我们从接收数据的同一线程调用 send 或 WriteFile API。我能想到的唯一副作用是当发送操作长时间挂起时，阻塞接收线程。但这只有在整个通信通道停止工作时才会发生，所以这并不重要。
Think about underlying I/O operations which are called by Boost using OS-specific API: sockets, serial communications or any other. There is no anything that prevents us to call send or WriteFile API from the same thread where data is received. The only side effect I can think about is when send operation hangs for a long time, blocking receiver thread. But this can happen only if the whole communication channel stopped working, so it doesn't really matter.