boost::asio io_service 在 stop() 之后没有返回

Question

我正在开发一个应用程序，它使用 boost::asio 在不同端口上侦听 TCP 和 UDP 数据包。我通过使用与 asio 教程示例中类似的服务器类来做到这一点，并将它们全部指向一个 io_service。

所以总的来说我的主要功能（win32 控制台应用程序）看起来像这样：

int main(int argc, char* argv[])
{
    //some initializations here

    try
    {
        asio::io_service io_service;
        TcpServer ServerTCP_1(io_service, /*port number here*/);
        TcpServer ServerTCP_2(io_service, /*port number here*/);
        UdpServer ServerUDP(io_service, /*port number here*/);

        io_service.run();
    }
    catch(std::exception& e)
    {
        std::cerr << e.what() << std::endl;
    }

    //cleanup code here

    return 0;
}

我还阅读了 HTTP 服务器示例，其中 signal_set 用于执行异步操作，该操作在退出信号进入时被激活（我也在服务器类中实现）。

这是我的TcpServer 课程：

class TcpServer : private noncopyable
{
public:
    TcpServer(asio::io_service& io_service, int port) : 
        acceptor_(io_service, tcp::endpoint(tcp::v4(), port)), 
        signals_(io_service), context_(asio::ssl::context::sslv3)
    {
        SSL_CTX_set_cipher_list(context_.native_handle(), "ALL");
        SSL_CTX_set_options(context_.native_handle(), SSL_OP_ALL);
        SSL_CTX_use_certificate_ASN1(context_.native_handle(), sizeof(SSL_CERT_X509), SSL_CERT_X509);
        SSL_CTX_use_PrivateKey_ASN1(EVP_PKEY_RSA, context_.native_handle(), SSL_CERT_RSA, sizeof(SSL_CERT_RSA));
        SSL_CTX_set_verify_depth(context_.native_handle(), 1);

        signals_.add(SIGINT);
        signals_.add(SIGTERM);
        signals_.add(SIGBREAK);
#if defined(SIGQUIT)
        signals_.add(SIGQUIT);
#endif // defined(SIGQUIT)
        signals_.async_wait(boost::bind(&TcpServer::handle_stop, this));

        start_accept();
    }

private:
    tcp::acceptor acceptor_;
    asio::ssl::context context_;
    asio::signal_set signals_;
    TcpConnection::pointer new_ssl_connection;

    void start_accept(){
        new_ssl_connection.reset(new TcpConnection(acceptor_.get_io_service(), context_));
        acceptor_.async_accept( new_ssl_connection->socket(), 
                                    boost::bind(&TcpServer::handle_acceptSSL, this, asio::placeholders::error));
    }

    void handle_acceptSSL(const system::error_code& error){
        if(!error)
            new_ssl_connection->start();
        start_accept();
    }
    void handle_stop(){
        acceptor_.close();
        printf("acceptor closed");
    }
};

现在，因为我有 3 个不同的服务器对象，他应该关闭它们的所有接受者，让 io_service 没有工作，这再次导致 io_service 从 run() 调用返回，这应该使程序进入清理代码在主函数中，对吗？ 除此之外，printf 调用也应该执行 3 次，还是？

首先io_service 没有返回，清理代码永远不会到达。 其次，控制台中最多只显示一个 printf 调用。

第三，通过一些调试，我发现当我退出程序时，handle_stop() 被调用一次，但由于某种原因，程序在句柄中的某处关闭（这意味着有时他会进入 printf 并在有时他只是去acceptor_.close()）

另一件可能值得一提的是程序在关闭后不会返回 0 而是这个（线程数不同）：

The thread 'Win32 Thread' (0x1758) has exited with code 2 (0x2).
The thread 'Win32 Thread' (0x17e8) has exited with code -1073741510 (0xc000013a).
The thread 'Win32 Thread' (0x1034) has exited with code -1073741510 (0xc000013a).
The program '[5924] Server.exe: Native' has exited with code -1073741510 (0xc000013a).

所以我想知道为什么会发生这种情况，如何修复它以及如何正确获取清理代码？

Answer 1

io_service 永远不会返回，因为io_service 中总是有工作。当acceptor::close()被调用时，acceptor的异步接受操作会立即被取消。这些已取消操作的处理程序将传递boost::asio::error::operation_aborted 错误。

在当前代码中，问题是始终启动新的异步接受操作的结果，即使acceptor 已关闭。因此，工作总是被添加到io_service。

void start_accept(){
  // If the acceptor is closed, handle_accept will be ready to run with an
  // error.
  acceptor_.async_accept(...,  handle_accept);
}

void handle_accept(const system::error_code& error){
  if(!error)
  {
    connection->start();
  }

  // Always starts a new async accept operation, even if the acceptor
  // has closed.
  start_accept();
}
void handle_stop(){
  acceptor_.close();
}

Boost.Asio 示例防止发生这种情况，检查acceptor_ 是否已在handle_accept 调用中关闭。如果acceptor_ 不再打开，则处理程序会提前返回，而不会向io_service 添加更多工作。

这是来自HTTP Server 1 示例的相关sn-p：

void server::handle_accept(const boost::system::error_code& e)
{
  // Check whether the server was stopped by a signal before this completion
  // handler had a chance to run.
  if (!acceptor_.is_open())
  {
    return;
  }

  if (!e)
  {
    connection_manager_.start(new_connection_);
  }

  start_accept();
}