call async_resolve.cancel(),but the callback handler of async_resolve doesn't return boost::asio::error::operation_aborted - boost

Question

i used boost asio to process http request and answer,to avoid async_resolve doesn't invoke its callback handler,i set a timeout,just like this:
void resolve()
{
resolver_.async_resolve(query,strand_.wrap(boost::bind(&connection::handle_resolve,
shared_from_this(),
boost::asio::placeholders::error,
boost::asio::placeholders::iterator)));
int cancel_num = timer_.expires_from_now(boost::posix_time::seconds(resolve_timeout_));
timer_.async_wait(strand_.wrap(boost::bind(&connection::handle_resolve_timeout,
shared_from_this(),
boost::asio::placeholders::error)));
}
void connection::handle_resolve_timeout(const boost::system::error_code& err)
{
if (err != boost::asio::error::operation_aborted)
{
resolver_.cancel();
}
}
void connection::handle_resolve(const boost::system::error_code& err,
boost::asio::ip::tcp::resolver::iterator endpoint_iterator)
{
timer_.cancel();
if(!err)
{
boost::asio::ip::tcp::endpoint endpoint = *endpoint_iterator;
socket_.async_connect(endpoint,strand_.wrap(boost::bind(&connection::handle_connect,
shared_from_this(),
boost::asio::placeholders::error,
++endpoint_iterator)));
//to distinct the type of timeout ,0:connect timeout,1:read timeout
int flag = 0;
int cancel_num = timer_.expires_from_now(boost::posix_time::seconds(connect_timeout_));
timer_.async_wait(strand_.wrap(boost::bind(&connection::handle_timeout,
shared_from_this(),
boost::asio::placeholders::error,
flag)));
}
else if(err != boost::asio::error::operation_aborted)
{
status_ = resolve_error;
check_.do_finish(shared_from_this());
}
else
{
FASTCHECK_INFO("resolve is canceled\n");
}
}
when resolve timeout ,i found the handle_resolve_timeout is invoked,but the handle_resolve doesn't return boost::asio::error::operation_aborted,why,i am puzzled,can someone can explain it for me?

Answer 1

According to the discussion on boost-users mailing list, resolver::cancel() is only able to cancel pending, queued resolve requests, not the one that's currently executing.

Answer 2

As a delayed follow up to #Cubbi's answer, this bug was also raised on the Boost issue tracker a few months after this question's thread. The Asio resolver API is slightly confusing because it suggests that any async_resolve() operation can be cancelled on demand. I had the same problem myself. It also turns out that in the Asio implementation, calls to async_resolve() makes a synchronous system call to getaddrinfo() behind the scenes. I discuss this interesting behavior in a recent codecast.