gpt4 book ai didi

c++ - 取消后无错误地调用 boost::asio 异步处理程序

转载 作者:可可西里 更新时间:2023-11-01 13:28:10 25 4
gpt4 key购买 nike

我的代码在单个线程中使用 boost::asio 和 io_service 来执行各种套接字操作。所有操作都是异步的,每个处理程序都依赖于 boost::system::error_code(特别是 boost::asio::error::operation_aborted)来确定操作。

在我更改逻辑以建立多个并发 连接并选择最快的连接之​​前,它一直运行良好。也就是说,当第一个 async_read_some 处理程序触发时,我取消其他套接字(关闭、关闭 - 一切)并继续当前的套接字。在 95% 的情况下,调用其他套接字的读取处理程序时会出现 operation_aborted 错误。然而有时,这些读取处理程序被调用时没有错误,告诉我它们已成功接收到 N 个字节。

但是 socket::cancel() 的文档 states :

This function causes all outstanding asynchronous connect, send and receive operations to finish immediately, and the handlers for cancelled operations will be passed the boost::asio::error::operation_aborted error.

那么问题来了:我真的可以依赖生产代码中的 operation_aborted 错误吗?如果可以的话,它是来自 boost 1.46.1 的 Asio 中的错误吗?如果我不能,是否有关于此的任何官方文档?

最佳答案

好的,答案:

  1. 不,我不能只依赖于 operation_aborted 错误。
  2. 当然,这不是 Asio 的错误,只是我这边缺乏经验。
  3. 官方有一点documentation .它适用于定时器,而不是套接字,但适用相同的原则:

如果调用 cancel() 时计时器已经过期,则异步等待操作的处理程序将:

  • 已经被调用;或者
  • 已排队等候在不久的将来调用。

基本上,我错误地假设如果我为 io_service 使用单个线程,那么在某些处理程序执行时每个操作都会被阻塞。

我报告的行为实际上很有道理,似乎每个使用 Asio 的人都知道这一点。我梳理了 Asio 的邮件列表,发现有很多关于这个主题的讨论 here , here , herehere .

For instance, a write operation may complete successfully while you are inside a handler but before you have got around to calling socket cancel, causing its completion handler to be posted to the queue. As I understand it, the error code is determined by the status of the operation that completed, not the state of the socket at the time the handler is picked off the queue and executed.

关于c++ - 取消后无错误地调用 boost::asio 异步处理程序,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/10718593/

25 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com